diff --git a/docs/manual/faq/all_in_one.html b/docs/manual/faq/all_in_one.html index 7c4e66f2e8..0ddbeeea0f 100644 --- a/docs/manual/faq/all_in_one.html +++ b/docs/manual/faq/all_in_one.html @@ -1,3 +1,7 @@ URI: all_in_one.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: all_in_one.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/faq/all_in_one.html.en b/docs/manual/faq/all_in_one.html.en index e37e4675e8..78082fab33 100644 --- a/docs/manual/faq/all_in_one.html.en +++ b/docs/manual/faq/all_in_one.html.en @@ -18,7 +18,8 @@
Apache > HTTP Server > Documentation > Version 2.1 > FAQ

Frequently Asked Questions

-

Available Languages:  en 

+

Available Languages:  en  | + ko 

The latest version of this FAQ is always available from the main Apache @@ -191,7 +192,8 @@

-

Available Languages:  en 

+

Available Languages:  en  | + ko 

diff --git a/docs/manual/faq/all_in_one.html.ko.euc-kr b/docs/manual/faq/all_in_one.html.ko.euc-kr new file mode 100644 index 0000000000..4f7eb2648f --- /dev/null +++ b/docs/manual/faq/all_in_one.html.ko.euc-kr @@ -0,0 +1,205 @@ + + + +자주 물어보는 질문 (FAQ) - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > FAQ

자주 물어보는 질문 (FAQ)

+
+

가능한 언어:  en  | + ko 

+
+ +

FAQ 최신판은 아파치 웹사이트 <http://httpd.apache.org/docs-2.1/faq/>에서 볼 수 + 있다.

+ +

아파치 2.0이 나온지 얼마 안되서 우리는 아직 자주 + 물어보는 질문 (FAQ)이 무엇인지 모른다. 내용이 채워질 + 때까지 여기에 해답이 없다면 아파치 + 1.3 FAQ도 참고하라.

+
+
+
top
+
+

주제

+
지원
문제가 생기면 어떻게 해결하나?
+
오류문
이 오류문이 무슨 뜻인가?
+
top
+
+

지원

+ + +

"왜 ... 안되나? 왜 ... 동작하지 않는가?" 문제가 생기면 + 할일

+ + +

아파치 서버 소프트웨어에 문제가 생기면 다음과 같은 + 단계를 따른다:

+ +
+
오류 로그(errorlog)를 확인하라!
+
아파치 서버는 문제가 생기면 도움을 주려고 노력한다. + 많은 경우 서버 오류 로그에 자세한 내용을 기록한다. + 이것만으로도 직접 (파일권한 등) 문제를 발견하고 고칠 수 + 있는 경우가 많다. 오류 로그의 기본 위치는 + /usr/local/apache2/logs/error_log이지만, + 정확한 위치는 설정파일의 ErrorLog 지시어를 참고하라.
+ +
FAQ를 + 확인하라!
+
아파치 웹사이트에서 항상 아파치 FAQ 최신판을 볼 수 + 있다.
+ +
아파치 버그 데이터베이스를 확인하라
+
아파치그룹(The Apache Group)에 보고된 대부분의 문제는 + 버그 + 데이터베이스에 기록된다. 새로 버그를 추가하기 전에, + 이미 알려졌거나(open) 해결된(closed) 버그가 있는지 확인하길 + 바란다. 이미 문제가 보고되었다면 "나도 + 이런 문제가 있다고" 보고하지 않길 바란다. 아직 + 해결되지 않았다면 주기적으로 상황을 확인하길 바란다. 또, + 데이터베이스에 기록되지 않고 이메일 교환으로 진행된 사항이 + 있을 수 있으니 처음 문제를 보고한 사람에게 연락해볼 수도 + 있다.
+ +
사용자 지원 공간에 + 문의한다
+

아파치에 대한 지식을 공유하길 원하는 활발한 사용자 + 공동체들이 있다. 일반적으로 이런 공동체에 참여하는 것이 + 문제의 답을 얻는 가장 좋고 빠른 방법이다.

+ +

사용자 + 메일링리스트

+ +

USENET 뉴스그룹:

+ +
    +
  • comp.infosystems.www.servers.unix + [news] + [google] +
    • + +
  • comp.infosystems.www.servers.ms-windows + [news] + [google] +
    • + +
  • comp.infosystems.www.authoring.cgi + [news] + [google] +
    • +
+ +
위의 방법이 모두 실패하면 버그 데이터베이스에 문제를 + 보고한다
+

위의 단계를 모두 시도하고도 해결책이 없다면, 버그를 + 보고하여 웹서버 개발자들에게 문제를 알리길 + 바란다.

+ +

core dump를 만들며 서버가 죽는 경우라면 (가능하면) + backtrace(역주; 문제가 실행파일의 정확히 어떤 지점에서 + 발생하였고, 프로그램이 그 지점까지 어떤 경로로 실행되었는지를 + 알려주는 정보)를 포함하길 바란다. 예를 들어,

+ +

+ # cd ServerRoot
+ # dbx httpd core
+ (dbx) where +

+ +

(ServerRoot, httpd, core + 파일의 실제 위치를 대신 사용하라. dbx 대신 + gdb를 사용해야 할 수도 있다.)

+
+
+ + +

도움을 얻으려면 누구에게 + 연락하나?

+

40명 가량의 자발적으로 참여한 개발자만으로는 수백만의 + 사용자에게 아파치에 대해 일일이 지원할 수 없다. 무료 지원을 + 얻으려면 사용자 + 공간에 참여하길 권한다.

+ +

아파치에 대한 직업적인 유료 지원은 여러 + 회사에서 제공한다.

+ +
top
+
+

오류문

+ + +

Invalid argument: + core_output_filter: writing data to the network

+ +

플래폼이 sendfile 시스템호출을 지원한다면, + 아파치는 응답의 속도를 빠르게하기위해 이 시스템호출을 사용한다. + 불행히도 어떤 시스템에서 아파치는 컴파일할때 + sendfile이 정상적으로 작동하지 않는데도 정상적으로 + 작동한다고 오판한다. 이 문제는 네트웍 파일시스템이나 비표준 + 파일시스템을 사용할때 자주 발생한다.

+ +

이 문제의 증상은 오류 로그(error log)에 위의 문구를 + 기록하거나 크기가 0이 아닌 파일에 대해 크기가 0인 응답을 + 하는 경우이다. 동적으로 내용을 생성할때는 + sendfile을 사용하지 않기때문에 일반적으로 정적인 + 파일을 요청할때만 문제가 발생한다.

+ +

문제를 해결하려면 서버가 sendfile을 사용하지 + 않도록 EnableSendfile + 지시어를 사용한다. 또, 이와 유사한 문제에 대해 EnableMMAP을 참고하라.

+ + + +

AcceptEx Failed

+ +

win32에서 AcceptEx 시스템호출에 대한 오류문을 + 나오면, Win32DisableAcceptEx + 지시어를 참고하라.

+ + + +

Premature end of script + headers

+ +

보통 CGI 스크립트에 문제가 있으면 브라우저에게 Internal + Server Error를 보내고 오류로그에 이 문구를 기록한다. + 이런 문제를 디버깅할때 CGI 투토리얼이 + 도움이 될 수 있다.

+ + +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/faq/all_in_one.xml.ko b/docs/manual/faq/all_in_one.xml.ko index 2234c36ec9..1299e0c3ba 100644 --- a/docs/manual/faq/all_in_one.xml.ko +++ b/docs/manual/faq/all_in_one.xml.ko @@ -3,7 +3,7 @@ ]> - + +오류문 - 자주 물어보는 질문 (FAQ) - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > FAQ

오류문 - 자주 물어보는 질문 (FAQ)

+
+

가능한 언어:  en  | + ko 

+
+
+
top
+
+

오류문

+ + +

Invalid argument: + core_output_filter: writing data to the network

+ +

플래폼이 sendfile 시스템호출을 지원한다면, + 아파치는 응답의 속도를 빠르게하기위해 이 시스템호출을 사용한다. + 불행히도 어떤 시스템에서 아파치는 컴파일할때 + sendfile이 정상적으로 작동하지 않는데도 정상적으로 + 작동한다고 오판한다. 이 문제는 네트웍 파일시스템이나 비표준 + 파일시스템을 사용할때 자주 발생한다.

+ +

이 문제의 증상은 오류 로그(error log)에 위의 문구를 + 기록하거나 크기가 0이 아닌 파일에 대해 크기가 0인 응답을 + 하는 경우이다. 동적으로 내용을 생성할때는 + sendfile을 사용하지 않기때문에 일반적으로 정적인 + 파일을 요청할때만 문제가 발생한다.

+ +

문제를 해결하려면 서버가 sendfile을 사용하지 + 않도록 EnableSendfile + 지시어를 사용한다. 또, 이와 유사한 문제에 대해 EnableMMAP을 참고하라.

+ + + +

AcceptEx Failed

+ +

win32에서 AcceptEx 시스템호출에 대한 오류문을 + 나오면, Win32DisableAcceptEx + 지시어를 참고하라.

+ + + +

Premature end of script + headers

+ +

보통 CGI 스크립트에 문제가 있으면 브라우저에게 Internal + Server Error를 보내고 오류로그에 이 문구를 기록한다. + 이런 문제를 디버깅할때 CGI 투토리얼이 + 도움이 될 수 있다.

+ + +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/faq/error.xml.ko b/docs/manual/faq/error.xml.ko index fb10064269..36560a15dd 100644 --- a/docs/manual/faq/error.xml.ko +++ b/docs/manual/faq/error.xml.ko @@ -1,7 +1,7 @@ - + +자주 물어보는 질문 (FAQ) - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1

자주 물어보는 질문 (FAQ)

+
+

가능한 언어:  en  | + ko 

+
+ +

FAQ 최신판은 아파치 웹사이트 <http://httpd.apache.org/docs-2.1/faq/>에서 볼 수 + 있다. 또, 검색하고 출력하기 편하게 FAQ를 한 페이지로 볼 수 있다.

+ +

아파치 2.0이 나온지 얼마 안되서 우리는 아직 자주 + 물어보는 질문 (FAQ)이 무엇인지 모른다. 내용이 채워질 + 때까지 여기에 해답이 없다면 아파치 + 1.3 FAQ도 참고하라.

+
+
top
+
+

주제

+
지원
문제가 생기면 어떻게 해결하나?
+
오류문
이 오류문이 무슨 뜻인가?
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/faq/index.xml.ko b/docs/manual/faq/index.xml.ko index 631d8d25be..af17a1aab7 100644 --- a/docs/manual/faq/index.xml.ko +++ b/docs/manual/faq/index.xml.ko @@ -3,7 +3,7 @@ ]> - + +지원 - 자주 물어보는 질문 (FAQ) - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > FAQ

지원 - 자주 물어보는 질문 (FAQ)

+
+

가능한 언어:  en  | + ko 

+
+
+
top
+
+

지원

+ + +

"왜 ... 안되나? 왜 ... 동작하지 않는가?" 문제가 생기면 + 할일

+ + +

아파치 서버 소프트웨어에 문제가 생기면 다음과 같은 + 단계를 따른다:

+ +
+
오류 로그(errorlog)를 확인하라!
+
아파치 서버는 문제가 생기면 도움을 주려고 노력한다. + 많은 경우 서버 오류 로그에 자세한 내용을 기록한다. + 이것만으로도 직접 (파일권한 등) 문제를 발견하고 고칠 수 + 있는 경우가 많다. 오류 로그의 기본 위치는 + /usr/local/apache2/logs/error_log이지만, + 정확한 위치는 설정파일의 ErrorLog 지시어를 참고하라.
+ +
FAQ를 + 확인하라!
+
아파치 웹사이트에서 항상 아파치 FAQ 최신판을 볼 수 + 있다.
+ +
아파치 버그 데이터베이스를 확인하라
+
아파치그룹(The Apache Group)에 보고된 대부분의 문제는 + 버그 + 데이터베이스에 기록된다. 새로 버그를 추가하기 전에, + 이미 알려졌거나(open) 해결된(closed) 버그가 있는지 확인하길 + 바란다. 이미 문제가 보고되었다면 "나도 + 이런 문제가 있다고" 보고하지 않길 바란다. 아직 + 해결되지 않았다면 주기적으로 상황을 확인하길 바란다. 또, + 데이터베이스에 기록되지 않고 이메일 교환으로 진행된 사항이 + 있을 수 있으니 처음 문제를 보고한 사람에게 연락해볼 수도 + 있다.
+ +
사용자 지원 공간에 + 문의한다
+

아파치에 대한 지식을 공유하길 원하는 활발한 사용자 + 공동체들이 있다. 일반적으로 이런 공동체에 참여하는 것이 + 문제의 답을 얻는 가장 좋고 빠른 방법이다.

+ +

사용자 + 메일링리스트

+ +

USENET 뉴스그룹:

+ +
    +
  • comp.infosystems.www.servers.unix + [news] + [google] +
    • + +
  • comp.infosystems.www.servers.ms-windows + [news] + [google] +
    • + +
  • comp.infosystems.www.authoring.cgi + [news] + [google] +
    • +
+ +
위의 방법이 모두 실패하면 버그 데이터베이스에 문제를 + 보고한다
+

위의 단계를 모두 시도하고도 해결책이 없다면, 버그를 + 보고하여 웹서버 개발자들에게 문제를 알리길 + 바란다.

+ +

core dump를 만들며 서버가 죽는 경우라면 (가능하면) + backtrace(역주; 문제가 실행파일의 정확히 어떤 지점에서 + 발생하였고, 프로그램이 그 지점까지 어떤 경로로 실행되었는지를 + 알려주는 정보)를 포함하길 바란다. 예를 들어,

+ +

+ # cd ServerRoot
+ # dbx httpd core
+ (dbx) where +

+ +

(ServerRoot, httpd, core + 파일의 실제 위치를 대신 사용하라. dbx 대신 + gdb를 사용해야 할 수도 있다.)

+
+
+ + +

도움을 얻으려면 누구에게 + 연락하나?

+

40명 가량의 자발적으로 참여한 개발자만으로는 수백만의 + 사용자에게 아파치에 대해 일일이 지원할 수 없다. 무료 지원을 + 얻으려면 사용자 + 공간에 참여하길 권한다.

+ +

아파치에 대한 직업적인 유료 지원은 여러 + 회사에서 제공한다.

+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/faq/support.xml.ko b/docs/manual/faq/support.xml.ko index 5086361aed..6606fb3ee4 100644 --- a/docs/manual/faq/support.xml.ko +++ b/docs/manual/faq/support.xml.ko @@ -1,7 +1,7 @@ - + +아파치 성능향상 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Miscellaneous Documentation

아파치 성능향상

+
+

가능한 언어:  en  | + ko 

+
+ + +

아파치 2.0은 기능과 포팅가능성과 성능의 균형이 맞도록 + 설계한 범용 웹서버이다. 벤치마크 기록을 세우기위해 설계하지 + 않았지만 아파치 2.0은 실제 많은 경우 높은 성능을 낸다.

+ +

아파치 1.3과 비교해서 2.0 버전은 처리량과 확장성(scalability)을 + 높이기위해 많은 최적화를 했다. 기본값으로 대부분 최적화한 + 값을 사용한다. 그러나 컴파일시 혹은 실행시 설정이 성능에 + 큰 영향을 줄 수 있다. 이 문서는 아파치 2.0의 성능을 향상하기위해 + 서버 관리자가 설정할 수 있는 옵션을 설명한다. 어떤 설정 + 옵션은 웹서버가 하드웨어와 운영체제의 기능을 더 잘 활용하도록 + 하는 반면, 어떤 옵션은 속도를 위해 기능을 희생한다.

+ +
+
+
top
+
+

하드웨어와 운영체제에 대해서

+ + + +

웹서버 성능에 가장 큰 영향을 주는 것은 메모리다. 스왑은 + 요청당 지연시간을 사용자가 "충분히 빠르다고" 생각하지 못하게 + 늘리기때문에 웹서버는 스왑을 하면 안된다. 느려지면 사용자는 + 정지하고 다시 접속하여 부하가 계속 증가한다. MaxClients 지시어를 조절하여 + 웹서버가 스왑을 할 정도로 많은 자식을 만들지않도록 해야 + 한다. 방법은 간단하다: top과 같은 도구에서 + 프로세스 목록을 보고 아파치 프로세스의 평균 메모리 사용량을 + 알아낸후, 전체 사용가능한 메모리에서 다른 프로세스들이 사용할 + 공간을 뺀 값에서 나눈다.

+ +

나머지는 평범하다: 충분히 빠른 CPU, 충분히 빠른 네트웍카드, + 충분히 빠른 디스크, 여기서 "충분히 빠른"은 실험을 해서 결정해야 + 한다.

+ +

운영체제는 보통 각자 알아서 선택할 일이다. 그러나 일반적으로 + 유용하다고 판명된 몇가지 지침이 있다:

+ + + +
top
+
+

실행시 설정에 대해서

+ + + +
관련된 모듈관련된 지시어
+ +

HostnameLookups와 DNS에 대해 고려할 점들

+ + + +

아파치 1.3 이전에 HostnameLookups의 기본값은 + On이였다. 요청을 마치기전에 DNS 검색이 끝나야 + 하므로 요청마다 지연이 생겼다. 아파치 1.3에서 이 설정의 + 기본값이 Off로 변경되었다. 로그파일의 주소를 + 호스트명으로 변환하려면 여러 로그처리 프로그램중 하나인, + 아파치에 포함된 logresolve + 프로그램을 사용하라.

+ +

로그처리 작업이 서버 성능에 악영향을 미치므로 실제 + 사용하는 웹서버가 아닌 다른 컴퓨터에서 로그파일을 후처리하길 + 바란다.

+ +

Allow + from domain이나 Deny from domain + 지시어를 사용한다면 (즉, IP 주소가 아닌 호스트명이나 도메인명을 + 사용한다면) 부득이 중복-역 DNS 검색을 (역검색을 한후 악의로 + 변경되었는지 확인하기위해 다시 검색) 해야 한다. 그러므로 + 성능을 높이기위해 이런 지시어에는 가능하면 이름대신 IP + 주소를 사용한다.

+ +

<Location /server-status> 섹션 등으로 + 지시어의 적용범위를 제한할 수 있음을 기억하라. 이 경우 + 조건에 맞는 요청에만 DNS 조회를 한다. 다음은 + .html과 .cgi 파일만 DNS 검색을 + 하는 예제다:

+ +

+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+ + HostnameLookups on
+ + </Files> +

+ +

그러나 CGI에서 DNS명이 필요할 뿐이라면, 필요한 특정 + CGI에서만 gethostbyname 호출을 하도록 고려해볼 + 수 있다.

+ + + +

FollowSymLinks와 SymLinksIfOwnerMatch

+ + + +

URL 공간에서 Options FollowSymLinks를 + 사용하지않고 Options SymLinksIfOwnerMatch를 + 사용하면 아파치는 심볼링크를 검사하기위해 시스템호출을 + 한번 더 해야 한다. 파일명의 각 부분마다 한번씩 더 호출을 + 한다. 예를 들어, 설정이 다음과 같고:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options SymLinksIfOwnerMatch
+ + </Directory> +

+ +

/index.html URI에 대한 요청이 있다고 가정하자. + 그러면 아파치는 /www, /www/htdocs, + /www/htdocs/index.html 각각에 대해 + lstat(2)를 호출한다. lstats + 결과를 캐싱하지 않기때문에 요청이 들어올 때마다 매번 같은 + 작업을 한다. 진짜 심볼링크 보안 검사를 원한다면 다음과 + 같이 할 수 있다:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options FollowSymLinks
+ + </Directory>
+
+ <Directory /www/htdocs>
+ + Options -FollowSymLinks +SymLinksIfOwnerMatch
+ + </Directory> +

+ +

이 경우 최소한 DocumentRoot 경로는 검사하지 + 않는다. DocumentRoot 밖에 있는 경로로 Alias나 RewriteRule을 사용한 + 경우에도 위와 비슷한 섹션이 필요하다. 심볼링크 보안을 + 고려하지 않고 최고의 성능을 얻으려면, + FollowSymLinks를 설정하고, + SymLinksIfOwnerMatch는 절대로 안된다.

+ + + +

AllowOverride

+ + + +

URL 공간에서 overrides를 허용한다면 (보통 + .htaccess 파일) 아파치는 파일명의 각 부분마다 + .htaccess를 열길 시도한다. 예를 들어,

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + AllowOverride all
+ + </Directory> +

+ +

/index.html URI에 대한 요청이 있다고 가정하자. + 아파치는 /.htaccess, /www/.htaccess, + /www/htdocs/.htaccess를 열려고 시도한다. + 해결책은 앞의 Options FollowSymLinks 경우와 + 비슷하다. 최고의 성능을 얻으려면 파일시스템에 대해서 항상 + AllowOverride None을 사용한다.

+ + + +

내용협상

+ + + +

가능하고 진짜 조금의 성능향상에도 관심이 있다면 내용협상을 + 막는다. 실제로 협상의 이득은 성능저하보다 작다. 서버를 + 빠르게 할 수 있다. 다음과 같이 와일드카드를 사용하는 대신:

+ +

+ DirectoryIndex index +

+ +

완전한 목록을 사용한다:

+ +

+ DirectoryIndex index.cgi index.pl index.shtml index.html +

+ +

가장 흔한 것을 앞에 둔다.

+ +

또, 디렉토리에서 파일들을 찾는 MultiViews + 보다는, 한 파일만 읽으면 필요한 정보를 얻을 수 있는 + type-map 파일을 직접 만드는 것이 더 빠름을 + 명심하라.

+ +

사이트에 내용협상이 필요하다면 협상을 위해 Options + MultiViews 지시어를 사용하기보다 type-map + 파일을 고려하라. 협상방법에 대한 자세한 설명과 + type-map 파일을 만드는 방법은 내용협상 문서를 참고하라.

+ + + +

메모리대응 (memory-mapping)

+ + + +

예를 들어, server-side-include를 처리하는 등 아파치 + 2.0이 전송할 파일을 읽을때 운영체제가 mmap(2) + 등을 지원한다면 파일을 메모리대응한다.

+ +

여러 플래폼에서 메모리대응을 성능을 향상한다. 그러나 + 메모리대응이 서버의 성능을 떨어트리고 심지어 안정성을 + 해치는 경우가 있다:

+ + + +

위의 조건에 해당하면 전송하는 파일을 메모리대응하지 + 않도록 EnableMMAP off를 사용해야 한다. (주의: + 이 지시어는 디렉토리별로 변경할 수 있다.)

+ + + +

Sendfile

+ + + +

아파치는 운영체제가 sendfile(2)을 지원하면 + 커널 sendfile을 사용하여 -- 예를 들어, 정적 파일을 서비스할때 + -- 전송할 파일을 직접 읽지않을 수 있다.

+ +

여러 플래폼에서 sendfile을 사용하면 read와 send를 따로 + 할 필요가 없어서 빨라진다. 그러나 sendfile을 사용하면 + 웹서버의 안정성을 해치게되는 경우가 있다:

+ + + +

위의 조건에 해당하면 파일을 sendfile 전송하지 않도록 + EnableSendfile off를 사용해야 한다. (주의: + 이 지시어는 디렉토리별로 변경할 수 있다.)

+ + + +

프로세스 생성

+ + + +

아파치 1.3 이전에는 MinSpareServers, MaxSpareServers, StartServers 설정이 모두 + 벤치마크 결과에 큰 영향을 미쳤다. 특히 아파치는 작업을 + 서비스하기위해 충분한 자식수에 다다를 때까지 "도달" 기간이 + 필요했다. 처음 StartServers개 자식을 + 만든후, MinSpareServers + 설정값까지 초당 자식을 하나씩 만들었다. 그래서 StartServers 기본값이 + 5인 서버에 클라이언트 100개가 동시에 접속하면 + 부하를 처리하기에 충분한 자식을 만들기까지 95초가 걸렸다. + 자주 재시작하지 않는 실제 서버에서는 잘 동작하지만, 10분간만 + 실행하는 벤치마크 결과는 매우 나쁘게 나온다.

+ +

초당 한개 규칙은 자식을 새로 시작하면서 서버에 무리를 + 주지 않으려고 정했다. 컴퓨터가 자식을 시작하느라 바쁘면 + 요청을 서비스할 수 없다. 그러나 이 규칙이 아파치의 체감 + 성능에 악영향을 주어 변경하였다. 아파치 1.3에서 초당 한개 + 규칙은 완화되었다. 코드는 자식 한개를 만들고, 1초 쉬고, + 두개를 만들고, 1초 쉬고, 네개를 만들고, 이런 식으로 초당 + 자식을 32개 만들때까지 지수로 증가한다. 자식수가 MinSpareServers 설정에 다다르면 + 증가를 중단한다.

+ +

이 경우 반응속도가 빨라져서 MinSpareServers, MaxSpareServers, StartServers를 거의 설정할 필요가 없다. 일초에 + 자식을 4개 이상 생성하면 ErrorLog에 기록한다. 이런 오류문이 + 많이 보이면 이 설정들을 조절하길 바란다. + mod_status 결과가 도움이 될 것이다.

+ +

프로세스 생성과 관련하여 MaxRequestsPerChild 설정은 + 프로세스를 종료한다. 기본값은 자식당 처리할 요청수에 제한이 + 없다는 0이다. 현재 설정이 30과 + 같이 매우 작은 값으로 설정되있다면, 값을 상당히 높힐 필요가 + 있다. SunOS나 오래된 Solaris 버전을 사용한다면, 메모리유출때문에 + 이 값을 10000 정도로 설정하라.

+ +

연결유지(keep-alive)를 사용한다면 자식들은 이미 열린 + 연결에서 추가 요청을 기다리며 아무것도 하지않기때문에 계속 + 바쁘다. KeepAliveTimeout의 + 기본값 15 초는 이런 현상을 최소화한다. 네트웍 + 대역폭과 서버 자원 간의 균형이 맞게 설정한다. + 연결유지의 대부분의 이점이 사라지기때문에 어떤 경우에도 + 이 값을 60 초 이상으로 올리지 마라.

+ + + +
top
+
+

컴파일시 설정에 대해서

+ + + +

MPM 선택

+ + + +

아파치 2.x는 다중처리모듈 + (MPMs)이라는 교체할 수 있는 동기화 모델을 지원한다. 아파치를 + 컴파일할때 MPM을 선택해야 한다. beos, + mpm_netware, mpmt_os2, + mpm_winnt와 같이 특정 플래폼에서만 사용할 + 수 있는 MPM도 있다. 일반적인 유닉스류 시스템은 여러 MPM + 중에 하나를 선택할 수 있다. 웹서버의 속도와 + 확장성(scalability)은 어떤 MPM을 선택했냐에 달렸다:

+ + + +

이 MPM들과 다른 MPM에 대해 더 자세한 정보는 MPM 문서를 참고하길 바란다.

+ + + +

모듈

+ + + +

메모리 사용량이 성능에서 가장 중요한 요인이기때문에 + 실제로 사용하지 않는 모듈을 제거해보자. 모듈을 DSO로 컴파일했다면 간단히 그 + 모듈에 대한 LoadModule 지시어를 주석처리하면 + 된다. 그래서 모듈을 제거하고 실행하여 사이트가 모듈없이도 + 정상적으로 동작하는지 살펴볼 수 있다.

+ +

반대로 모듈이 아파치 실행파일에 정적으로 링크되있다면 + 원하지 않는 모듈을 제거하기위해 아파치를 재컴파일해야 + 한다.

+ +

여기서 당연히 어떤 모듈을 사용하고 사용하지 말지 + 의문이 생긴다. 정답은 웹사이트마다 다르다. 그러나 아마도 + 최소한 mod_mime, + mod_dir, mod_log_config + 모듈은 사용할 것이다. 물론 웹사이트에 로그파일이 필요없다면 + mod_log_config는 없어도 된다. 그러나 추천하지 + 않는다.

+ + + +

Atomic 명령

+ + + +

mod_cache 같은 모듈과 최근 개발중인 + worker MPM은 APR의 atomic API를 사용한다. 이 API는 경량급 + 쓰레드 동기화를 위할 atomic 명령을 제공한다.

+ +

기본적으로 APR은 각 운영체제/CPU 플래폼에서 가장 효율적인 + 방법을 사용하여 이 명령을 구현한다. 예를 들어, 여러 최신 + CPU에는 하드웨어로 atomic compare-and-swap (CAS) 연산을 + 하는 명령어가 있다. 그러나 어떤 플래폼에서 APR은 이런 + 명령어가 없는 오래된 CPU와 호환성을 위해 더 느린 mutex기반 + 구현을 기본적으로 사용한다. 이런 플래폼에서 아파치를 + 컴파일할때 아파치를 최신 CPU에서만 실행할 계획이라면, + 아파치를 구성할때 --enable-nonportable-atomics + 옵션을 사용하여 더 빠른 atomic 구현을 선택할 수 있다:

+ +

+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes +

+ +

--enable-nonportable-atomics 옵션은 다음과 + 같은 플래폼에 영향이 있다:

+ + + + + +

mod_status와 ExtendedStatus On

+ + + +

아파치를 컴파일할때 mod_status를 포함하고 + 실행할때 ExtendedStatus On을 설정하면 아파치는 + 요청을 받을때마다 gettimeofday(2)(혹은 운영체제에 + 따라 times(2))를 두번 호출하고 (1.3 이전에는) + time(2)도 추가로 여러번 호출한다. 상태 보고서에 + 동작시간이 필요하기 때문이다. 최상의 성능을 얻으려면 + (기본값인) ExtendedStatus off를 설정한다.

+ + + +

accept 직렬화 - 여러 소켓

+ + + +

주의:

+

아래 문서는 아파치 웹서버 2.0 버전에서 변경된 내용을 + 담고 있지 않다. 아직도 유효한 정보가 있지만, 주의해서 + 사용하길 바란다.

+
+ +

유닉스 소켓 API의 단점을 설명한다. 웹서버가 여러 포트 + 혹은 여러 주소를 기다리기위해 여러 Listen을 사용한다고 가정하자. + 연결이 가능한지 각 소켓을 검사하기위해 아파치는 + select(2)를 사용한다. select(2)는 + 소켓에 기다리고 있는 연결이 없는지 혹은 최소한 + 한개 있는지 알려준다. 아파치에는 여러 자식이 있고, + 쉬고 있는 모든 자식은 동시에 새로운 연결을 검사한다. 원래 + 구현은 다음과 비슷하다 (이 예는 코드에서 가져오지 않았다. + 단지 설명하기위한 용도로 만들었다.):

+ +

+ for (;;) {
+ + for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+ + }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+ + }
+ + }
+ if (new_connection != -1) break;
+ + }
+ process the new_connection;
+ + } +

+ +

그러나 위의 단순한 구현에는 심각한 고갈(starvation) + 문제가 있다. 여러 자식이 동시에 이 반복문을 실행하면, + 요청을 기다리며 모두 select에서 멈춘다. 이때 + 어떤 소켓에 요청이 하나라도 들어오면 모든 자식이 깨어난다 + (깨어나는 자식의 개수는 운영체제와 타이밍에 따라 다르다). + 이들은 모두 연결을 accept하길 시도한다. 그러나 + (아직도 한 연결만 대기중이라면) 한 자식만 성공하고, 나머지는 + accept에서 멈춘다. 그러면 이 자식들은 + 한 소켓의 요청만을 서비스하도록 묶여서, 그 소켓으로 새로운 + 요청이 충분히 들어와서 모든 자식을 깨울때까지 정지해있다. + 이런 고갈 문제는 PR#467에 + 처음 보고되었다. 최소한 두가지 해결책이 있다.

+ +

한가지는 소켓을 대기하지 않도록 (non-blocking) 만드는 + 방법이다. 이 경우 자식이 accept를 해도 멈추지 + 않고, 즉시 진행할 수 있다. 그러나 CPU 시간을 낭비한다. + select에서 쉬는 자식이 10개 있고, 새로 연결이 + 한개 들어왔다고 가정하자. 그러면 이 자식중 9개는 깨어나서 + 연결을 accept하길 시도하고 실패하면 아무 + 일도 하지 않고 다시 select를 반복한다. 다시 + select로 돌아올 때까지 어떤 자식도 다른 소켓에 + 들어온 요청을 서비스하지 않는다. (다중프로세서 컴퓨터에서) + 쉬는 자식 개수만큼 CPU 개수가 있는 드문 경우가 아니라면 + 이 해결책은 별로 좋아보이지 않는다.

+ +

다른 방법은 아파치가 사용하는 방법으로 내부 반복문에 + 한 자식만을 들여보낸다. 반복문은 다음과 같다 (차이를 + 강조했음):

+ +

+ for (;;) {
+ + accept_mutex_on ();
+ for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+ + }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+ + }
+ + }
+ if (new_connection != -1) break;
+ + }
+ accept_mutex_off ();
+ process the new_connection;
+ + } +

+ +

accept_mutex_on과 accept_mutex_off + 함수는 mutex 세마포어를 + 구현한다. 한번에 오직 한 자식만이 mutex를 가질 수 있다. + mutex를 구현하는 방법은 여러가지이다. 구현 방법은 (1.3 + 이전) src/conf.h나 (1.3과 그 이후) + src/include/ap_config.h에 정의되있다. 어떤 + 아키텍쳐는 잠금(locking) 방법을 선택하지 않기때문에, 이런 + 아키텍쳐에서 여러 Listen 지시어를 사용하면 + 위험하다.

+ +

실행시 AcceptMutex 지시어를 사용하여 + mutex 구현을 변경할 수 있다.

+ +
+
AcceptMutex flock
+ +
+

이 방법은 잠금파일을 잠그기위해 flock(2) + 시스템호출을 사용한다 (잠금파일 위치는 LockFile 지시어로 지정).

+
+ +
AcceptMutex fcntl
+ +
+

이 방법은 잠금파일을 잠그기위해 fcntl(2) + 시스템호출을 사용한다 (잠금파일 위치는 LockFile 지시어로 지정).

+
+ +
AcceptMutex sysvsem
+ +
+

(1.3과 그 이후) 이 방법을 SysV식 세마포어를 사용하여 + mutex를 구현한다. 불행히도 SysV식 세마포어는 나쁜 + 부작용이 있다. 하나는 아파치가 세마포어를 정리하지 + 않고 죽을 수 있는 점이다 (ipcs(8) manpage + 참고). 다른 하나는 웹서버와 동일한 uid로 실행하는 + CGI가 (즉, suexec나 + cgiwrapper를 사용하지않는 한 모든 CGI) + 세마포어 API를 사용하여 서비스거부공격을 할 수 있는 + 점이다. 이런 이유때문에 IRIX를 제외한 아키텍쳐에서 + 이 방법을 사용하지 않는다 (대부분의 IRIX 컴퓨터에서 + 앞의 두 방법은 지나치게 버겁다).

+
+ +
AcceptMutex pthread
+ +
+

(1.3과 그 이후) 이 방법은 POSIX mutex를 사용하기때문에 + POSIX 쓰레드 규약을 완전히 구현한 아키텍쳐라면 모두 + 사용가능하지만, (2.5 이후) Solaris에서만 그것도 특정 + 구성에서만 동작하는 듯하다. 이 방법을 시도해본다면 + 서버가 멈춰서 응답을 안하는지 살펴봐야 한다. 정적 + 내용만 서비스하는 서버는 잘 동작하는 것 같다.

+
+ +
AcceptMutex posixsem
+ +
+

(2.0과 그 이후) 이 방법은 POSIX 세마포어를 사용한다. + mutex를 가진 프로세스의 쓰레드가 죽는다면(segfault) + 세마포어 소유권이 회복되지 않아서 웹서버가 멈춘다.

+
+ +
+ +

시스템에 위 목록에 없는 직렬화(serialization) 방법이 + 있다면 그 방법을 사용하는 코드를 APR에 추가할 가치가 있다.

+ +

고려는 해봤지만 구현하지않은 다른 방법은 부분적으로 + 반복문을 직렬화하는 방법이다. 즉, 프로세서를 몇개만 들여보내는 + 것이다. 이 방법은 여러 자식을 동시에 실행할 수 있어서 + 직렬화때문에 전체 대역폭을 활용하지 못하는 다중프로세서 + 컴퓨터에서만 관심을 가져볼 수 있다. 앞으로 살펴볼 부분이지만, + 매우 병렬화된 웹서버가 흔하지 않아서 우선순위가 낮다.

+ +

최상의 성능을 얻기위해서는 여러 Listen 문을 사용하지 않는 + 것이 이상적이다. 그러나 계속 설명한다.

+ + + +

accept 직렬화 - 소켓 한개

+ + + +

앞의 설명은 다중소켓 서버에는 좋지만, 소켓이 한개인 + 서버는 어떤가? 연결이 도착할때까지 모든 자식이 + accept(2)에서 멈춰있기때문에 이론상 같은 + 문제가 발생하지 않고, 고갈 문제도 없다. 그러나 실제로는 + 앞에서 말한 대기하지 않는 (non-blocking) 방법에서 발생하는 + "공회전(spinning)" 현상을 감추고 있다. 대부분의 TCP 스택은 + 연결이 도착하면 커널이 accept에서 멈춰있는 + 모든 자식을 깨우도록 구현되있다. 프로세스중 한개가 연결을 + 얻고 사용자영역으로 돌아가고, 나머지는 커널에서 공회전하여 + 연결이 없음을 발견하면 다시 잠을 잔다. 사용자영역 코드에서는 + 이런 공회전을 알 수 없지만, 분명히 존재한다. 그래서 다중소켓의 + 대기하지 않는 방법과 동일하게 부하를 높이는 불필요한 행동이 + 일어난다.

+ +

그래서 우리는 여러 아키텍쳐에서 소켓이 한개인 경우에도 + 직렬화하면 더 "잘" 동작함을 발견했다. 그래서 거의 대부분의 + 경우 기본적으로 직렬화를 사용한다. 리눅스에서 (커널 2.0.30, + 128Mb 메모리에 듀얼 Pentium pro) 실험한 결과 소켓 한개를 + 직렬화하면 하지 않은 경우에 비해 초당 요청이 3% 미만 + 줄어들었다. 그러나 직렬화를 하지 않은 경우 요청당 100ms + 지연이 발생했다. 이 지연은 아마도 LAN에서 발생하는 긴 + 연결선때문일 것이다. 소켓이 한개인 경우 직렬화를 사용하지 + 않으려면 SINGLE_LISTEN_UNSERIALIZED_ACCEPT를 + 정의한다.

+ + + +

Close 지연(lingering)

+ + + +

+ draft-ietf-http-connection-00.txt 8절에서 설명하듯이 + 안정적인 웹서버가 되려면, 통신의 양 방향을 + 독립적으로 닫을 수 있어야 한다 (TCP 연결은 쌍방향이고, + 방향은 서로 독립적이다). 이점을 다른 서버에서는 자주 + 간과하지만, 아파치는 1.2부터 정확히 구현해왔다.

+ +

이 기능을 부주의하게 아파치에 추가했을때 여러 유닉스 + 버전에서 많은 문제가 발생했다. TCP 규약은 + FIN_WAIT_2에 타임아웃이 있다고 정하지 않았지만, + 금지하지도 않았다. 타임아웃이 없는 시스템에서 아파치 1.2는 + 많은 소켓을 영원히 FIN_WAIT_2 상태로 만들었다. + 많은 경우 이 문제는 제작사가 제공하는 최신 TCP/IP 패치를 + 적용하여 해결할 수 있다. 그러나 제작사가 패치를 발표하지 + 않는 경우가 (즉, SunOS4 -- 소스 라이선스가 있는 + 사람은 직접 패치할 수 있지만) 있기때문에 이 기능을 사용하지 + 않기로 결정했다.

+ +

방법은 두가지다. 하나는 소켓 옵션 SO_LINGER를 + 사용하는 방법이다. 그러나 불행히도 대부분의 TCP/IP 스택은 + 이 옵션을 올바로 구현하지 않았다. 올바로 구현한 스택에서 + 조차도 (즉, 리눅스 2.0.31) 이 방법은 다음 방법보다 + 더 cpu를 잡아먹는다.

+ +

아파치는 보통 (http_main.c에 있는) + lingering_close라는 함수를 사용한다. 이 함수는 + 대충 다음과 같다:

+ +

+ void lingering_close (int s)
+ {
+ + char junk_buffer[2048];
+
+ /* shutdown the sending side */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+ + select (s for reading, 2 second timeout);
+ if (error) break;
+ if (s is ready for reading) {
+ + if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ + break;
+ + }
+ /* just toss away whatever is here */
+ + }
+ + }
+
+ close (s);
+ + } +

+ +

이 코드는 연결을 닫을때 더 CPU를 사용하지만, 안정적인 + 구현을 위해 필요하다. HTTP/1.1이 더 널리 퍼지고 모든 연결을 + 유지한다면(persistent), 연결을 받는 비용은 여러 요청을 + 처리하면서 상쇄될 것이다. 위험하게도 + NO_LINGCLOSE를 정의하여 이 기능을 사용하지 + 않을 수 있지만, 절대로 권하지 않는다. 특히 HTTP/1.1 + 파이프라인 (역주; 연결유지 상태에서 응답을 기다리지 + 않고 여러 요청을 보내는 기술) 연결유지에는 + lingering_close가 필수적이다 (그리고 + 파이프라인 연결이 더 빠르기때문에 사용하길 바랄 것이다).

+ + + +

Scoreboard 파일

+ + + +

아파치의 부모와 자식은 scoreboard라는 것을 통해 서로 + 통신한다. 이상적으로는 scoreboard를 공유메모리로 구현해야 + 한다. 우리 개발자가 해당 운영체제에 접근할 수 있거나 상세한 + 포팅 결과를 받은 경우 보통 공유메모리를 사용하여 구현한다. + 나머지는 디스크에 있는 파일을 사용하여 구현한다. 디스크에 + 있는 파일은 느리고 신뢰도가 떨어진다 (기능도 더 적다). + src/main/conf.h 파일에서 사용하는 아키텍쳐를 + 찾아서 USE_MMAP_SCOREBOARD 혹은 + USE_SHMGET_SCOREBOARD인지 확인한다. 둘중 + 하나를 (각각 함께 사용할 HAVE_MMAP이나 + HAVE_SHMGET도 같이) 정의하면 공유메모리 코드를 + 사용한다. 시스템이 다른 종류의 공유메모리를 사용한다면 + src/main/http_main.c 파일을 수정하여 아파치에서 + 공유메모리를 사용할 수 있도록 훅(hook)을 추가하라. (또한 + 패치를 우리에게 보내주길 바란다.)

+ +
역사적 설명: 아파치의 리눅스 버전은 아파치 1.2 버전부터 + 공유메모리를 사용하기 시작했다. 리눅스에서 초기 아파치 + 버전이 느리고 신뢰도가 떨어졌기 때문이다.
+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

모듈을 동적으로 읽어들이지 않는다면 (가능한 조금이라도 + 성능을 높이기위해 이 글을 읽는다면 아마도 모듈을 동적으로 + 읽어들이지 않을 것이다), 서버를 컴파일할때 + -DDYNAMIC_MODULE_LIMIT=0을 추가한다. 그러면 + 모듈을 동적으로 읽어들이기위해 할당하는 메모리를 절약한다.

+ + + +
top
+
+

부록: 시스템호출 기록을 자세히 분석하기

+ + + +

다음은 Solaris 8에서 worker MPM을 사용한 아파치 2.0.38의 + 시스템호출 기록(trace)이다. 아래 명령어를 사용하여 기록을 + 얻었다:

+ +

+ truss -l -p httpd_child_pid. +

+ +

-l 옵션을 사용하면 truss는 시스템호출을 + 하는 LWP (lightweight process, 경량급 프로세스--Solaris의 + 커널수준 쓰레드) ID를 같이 기록한다.

+ +

다른 시스템에는 strace, ktrace, + par 같은 시스템호출 추적 도구가 있다. 결과는 + 비슷하다.

+ +

클라이언트는 웹서버에게 크기가 10KB인 정적 파일을 요청한다. + 정적인 파일을 요청하지 않거나 내용협상하는 요청을 한 경우 + 기록이 매우 다르다 (때로는 매우 알아보기 힘들다).

+ + 
/67:    accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
+/67:    accept(3, 0x00200BEC, 0x00200C0C, 1)            = 9
+ +

위에서 연결대기(listener) 쓰레드가 LWP #67에서 실행됨을 + 알 수 있다.

+ +
accept(2) 직렬화를 사용하지 않음을 주목하라. + 여러 포트를 기다리지않는 경우 이 플래폼의 worker MPM은 + 기본적으로 직렬화하지 않은 accept를 사용한다.
+ + 
/65:    lwp_park(0x00000000, 0)                         = 0
+/67:    lwp_unpark(65, 1)                               = 0
+ +

연결은 받아들이고(accept) 연결대기 쓰레드는 + worker 쓰레드를 깨워서 요청을 처리하게 한다. 아래 기록에서 + 요청을 처리하는 worker 쓰레드가 LWP #65임을 알 수 있다.

+ + 
/65:    getsockname(9, 0x00200BA4, 0x00200BC4, 1)       = 0
+ +

가상호스트를 구현하기위해 아파치는 연결을 받아들인 + 지역(local) 소켓 주소를 알아야 한다. (가상호스트를 사용하지 + 않거나 Listen + 지시어에 와일드카드 주소를 사용하지 않은 경우 등) 많은 경우 + 이 호출을 없앨 수 있다. 그러나 아직 이런 최적화 작업이 + 안되있다.

+ + 
/65:    brk(0x002170E8)                                 = 0
+/65:    brk(0x002190E8)                                 = 0
+ +

brk(2) 호출은 힙(heap)에서 메모리를 할당한다. + 웹서버는 대부분의 요청 처리시 자체 메모리 + 할당자(apr_pool과 apr_bucket_alloc)를 + 사용하기때문에 시스템호출 기록에서 이 시스템호출을 보기가 + 드물다. 이 기록에서 웹서버는 시작하자마자 자체 메모리 할당자가 + 사용할 메모리블록을 얻기위해 malloc(3)을 호출한다.

+ + 
/65:    fcntl(9, F_GETFL, 0x00000000)                   = 2
+/65:    fstat64(9, 0xFAF7B818)                          = 0
+/65:    getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
+/65:    fstat64(9, 0xFAF7B818)                          = 0
+/65:    getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
+/65:    setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
+/65:    fcntl(9, F_SETFL, 0x00000082)                   = 0
+ +

다음 worker 쓰레드는 클라이언트의 연결(파일기술자 9)을 + 대기안함(non-blocking) 상태로 바꾼다. setsockopt(2)와 + getsockopt(2) 호출은 Solaris의 libc가 소켓에 + 대한 fcntl(2)을 어떻게 처리하는지 보여준다.

+ + 
/65:    read(9, " G E T   / 1 0 k . h t m".., 8000)     = 97
+ +

worker 쓰레드는 클라이언트로 부터 요청을 읽는다.

+ + 
/65:    stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
+/65:    open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10
+ +

웹서버 설정은 Options FollowSymLinks와 + AllowOverride None이다. 그래서 요청한 파일경로의 + 각 디렉토리에 대해 lstat(2)하거나 + .htaccess 파일을 검사할 필요가 없다. 파일을 + 검사하기위해, 1) 파일이 있는지, 2) 디렉토리가 아닌 일반파일인지, + stat(2) 호출만 하면 된다.

+ + 
/65:    sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C)      = 10269
+ +

이 경우 웹서버는 한번의 sendfilev(2) 시스템호출로 + HTTP 응답헤더와 요청한 파일을 전송할 수 있다. Sendfile 지원여부는 + 운영체제마다 다르다. 다른 시스템이라면 sendfile(2)을 + 호출하기 전에 헤더를 보내기위해 write(2)나 + writev(2) 호출을 한다.

+ + 
/65:    write(4, " 1 2 7 . 0 . 0 . 1   -  ".., 78)      = 78
+ +

write(2) 호출은 접근로그(access log)에 요청을 + 기록한다. 이 기록에 time(2) 호출이 없음을 주목하라. + 아파치 1.3과 달리 아파치 2.0은 시간을 알기위해 + gettimeofday(3)를 사용한다. + gettimeofday를 최적화한 리눅스와 Solaris 같은 + 몇몇 운영체제에서는 일반적인 시스템호출 부담이 없다.

+ + 
/65:    shutdown(9, 1, 1)                               = 0
+/65:    poll(0xFAF7B980, 1, 2000)                       = 1
+/65:    read(9, 0xFAF7BC20, 512)                        = 0
+/65:    close(9)                                        = 0
+ +

worker 쓰레드는 연결을 지연닫기(lingering close)한다.

+ + 
/65:    close(10)                                       = 0
+/65:    lwp_park(0x00000000, 0)         (sleeping...)
+ +

마지막으로 worker 쓰레드는 방금 전송한 파일을 닫고, + 연결대기(listener) 쓰레드가 다른 연결을 할당할 때까지 + 정지한다.

+ + 
/67:    accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
+ +

그동안 연결대기 쓰레드는 연결을 (모든 worker가 작업중이면 + 연결대기 쓰레드를 멈추는 worker MPM의 흐름제어 기능에 따라) + worker 쓰레드에 할당하자마자 다른 연결을 받아들일 수 있다. + 이 기록에는 나오지 않지만, worker 쓰레드가 방금 받은 연결을 + 처리하는 동안 다음 accept(2)가 (요청이 매우 + 많은 경우 항상) 일어날 수 있다.

+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.xml.ko b/docs/manual/misc/perf-tuning.xml.ko index c550863815..0a05318957 100644 --- a/docs/manual/misc/perf-tuning.xml.ko +++ b/docs/manual/misc/perf-tuning.xml.ko @@ -1,7 +1,7 @@ - + +관련 표준 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Miscellaneous Documentation

관련 표준

+
+

가능한 언어:  en  | + ko 

+
+ +

이 문서에는 간단한 설명과 함께 아파치 웹서버가 따르는 + 모든 관련 표준을 열거한다.

+ +

아래 정보에 더하여 다음 자료도 살펴봐야 한다:

+ + + +

주의

+

이 문서는 아직 완전하지 않다.

+
+ +
+
+
top
+
+

HTTP 권고

+ +

어떤 모듈을 컴파일하고 사용하는지와 관계없이 기본적으로 + 웹서버인 아파치는 다음 IETF 권고(recommendation)를 따른다:

+ +
+
RFC 1945 + (Informational)
+ +
하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol, + HTTP)은 분산, 협동, 하이퍼매체 정보 시스템에 필요한 빠르고 + 가벼운 어플리케이션 수준(application-level) 프로토콜이다. + 이 문서는 HTTP/1.0을 설명한다.
+ +
RFC 2616 + (Standards Track)
+ +
하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol, + HTTP)은 분산, 협동, 하이퍼매체 정보 시스템을 위한 어플리케이션 + 수준 프로토콜이다. 이 문서는 HTTP/1.1을 설명한다.
+ +
RFC 2396 + (Standards Track)
+ +
표준 자원 식별자 (Uniform Resource Identifier, URI)는 + 추상적 혹은 물리적 자원을 식별하기위한 짧은 문자열이다.
+
+ +
top
+
+

HTML 권고

+ +

하이퍼텍스트 마크업 언어 (Hypertext Markup Language, + HTML)와 관련하여 아파치는 다음 IETF 권고와 W3C 권고를 따른다:

+ +
+
RFC 2854 + (Informational)
+ +
이 문서는 HTML 개발과정을 요약하고, 관련 W3C 권고를 + 기반으로 "text/html" MIME type을 정의한다.
+ +
HTML 4.01 규약 + (Errata) +
+ +
이 규약은 월드와이드웹의 출판언어인 하이퍼텍스트 마크업 + 언어 (Hypertext Markup Language, HTML)를 정의한다. 이 + 규약은 HTML 4의 하위버전인 HTML 4.01을 정의한다.
+ +
HTML 3.2 참고 규약
+ +
하이퍼텍스트 마크업 언어 (Hypertext Markup Language, + HTML)는 플래폼과 무관한 하이퍼텍스트 문서를 위한 간단한 + 마크업 언어이다. HTML 문서는 SGML 문서이기도 하다.
+ +
XHTML™ 1.1 - + 모듈기반 XHTML + (정오표) +
+ +
이 권고는 Modularization of XHTML에서 정의한 모듈 + 플레임워크와 모듈들을 기반으로 새로운 XHTML document type을 + 정의한다.
+ +
XHTML™ 1.0 + 확장 하이퍼텍스트 마크업 언어 (Extensible HyperText Markup + Language) (Second Edition) + (정오표) +
+ +
이 문서는 HTML 4를 XML 1.0으로 재구성한 XHTML 1.0의 + 두번째 버전과 HTML 4에 해당하는 세가지 DTD를 정의한다.
+
+ +
top
+
+

인증

+ +

인증방법에 대해 아파치는 다음 IETF 권고를 따른다:

+ +
+
RFC 2617 + (Draft standard)
+ +
Basic Access Authentication 규약을 포함한 "HTTP/1.0".
+ +
+ +
top
+
+

언어/국가 코드

+ +

아래 링크에 ISO와 다른 언어/국가 코드 정보가 있다:

+ +
+
ISO 639-2
+ +
ISO 639는 언어의 이름을 나타내는 두가지 언어 코드를 + 제공한다. 하나는 (639-1) 두 글자 코드이고 다른 하나는 + (이 문서) 세 글자 코드이다.
+ +
+ ISO 3166-1
+ +
이 문서는 ISO 3166-1과 ISO 3166-1-alpha-2 코드에 따라 + 알파벳 순서로 (영어로 짧은 공식이름) 국가명을 열거한다.
+ +
BCP 47 + (Best Current Practice), + RFC 3066
+ +
이 문서는 정보 객체에 사용한 언어를 알리기위해 사용할 + 언어 태그와 언어 태그에 사용할 값을 등록하는 방법, 언어 + 태그를 찾는 방식을 설명한다.
+ +
RFC 3282 + (Standards Track)
+ +
이 문서는 MIME 내용 부분과 웹 문서와 같은 RFC 822식 + 헤더가 있는 정보의 언어를 알리기위한 "Content-language:" + 헤더와, 선호하는 언어를 나타내는 "Accept-Language:" 헤더를 + 정의한다.
+
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/relevant_standards.xml.ko b/docs/manual/misc/relevant_standards.xml.ko index b6ad78f82f..cc31616cf5 100644 --- a/docs/manual/misc/relevant_standards.xml.ko +++ b/docs/manual/misc/relevant_standards.xml.ko @@ -1,7 +1,7 @@ - + +URL 재작성 지침서 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Miscellaneous Documentation

URL 재작성 지침서

+
+

가능한 언어:  en  | + ko 

+
+ +
+

원저자
+ Ralf S. Engelschall <rse@apache.org>
+ 1997년 12월

+
+ +

이 문서는 mod_rewrite 참조 문서를 보충한다. + 이 문서는 웹관리자가 실제 작업에서 부딪치게되는 전형적인 + URL관련 문제를 해결하기위해서 어떻게 아파치 + mod_rewrite를 사용하는지 설명한다. URL + 재작성 규칙을 설정하여 문제를 해결하는 방법을 자세히 설명한다.

+ +
+
+
top
+
+

mod_rewrite 소개

+ + + +

아파치 mod_rewrite 모듈은 굉장하다. + 즉, URL을 조작할 수 있는 강력하고 실로 정교한 모듈이다. + 상상해왔던 거의 모든 종류의 URL 조작이 가능하다. 그러나 + 그 대가로 사용하기 복잡하다. mod_rewrite의 + 최대 단점은 초보자가 이해하고 사용하기 쉽지 않다는 점이다. + 심지어 아파치 전문가도 종종 mod_rewrite의 + 새로운 용도를 발견한다.

+ +

다른 말로: mod_rewrite에 대해 당신은 + 처음에 겁을 먹고 절대로 다시 사용하지 않거나, 강력함에 매료되어 + 앞으로 삶 동안 사랑에 빠질 것이다. 이 글은 첫번째 경우를 + 막기위해 이미 알려진 몇가지 성공사례를 소개하려고 한다.

+ +
top
+
+

실용적인 해결책

+ + + +

이제 내가 직접 만들었거나 다른 사람들이 만든 많은 실용적인 + 해결책이 나온다. 예제에서 URL 재작성의 흑마술을 마음껏 배우길 + 바란다.

+ +
주의: 서버 설정에 따라 상황에 맞게 + 예제를 조금 수정해야 할 경우가 있다. 예를 들어, 추가로 + mod_alias, mod_userdir + 등을 사용한다면 [PT] 플래그를 추가한다. 혹은 + 주서버설정/가상호스트 사용장소가 아닌 .htaccess + 사용장소에 알맞게 규칙을 수정할 수도 있다. 사용하기 전에 + 항상 규칙이 어떤 기능을 하는지 이해하도록 해라. 그러면 문제를 + 피할 수 있다.
+ +
top
+
+

URL 구조

+ + + +

기준이 되는 URL

+ + + +
+
상황설명:
+ +
+

한 리소스에 대해 여러 URL을 가지는 웹서버가 있다. + 보통 (실제 사용하고 알려져야 할) 기준이 되는 URL과, + 단축 혹은 내부 용도의 URL이 있다. 사용자가 요청에 + 어떤 URL을 사용하던지 기준이 되는 URL만을 보여줘야 + 한다.

+
+ +
해결책:
+ +
+

기준이 되지않는 모든 URL을 브라우저가 알도록 고치기위해 + 외부 HTTP 리다이렉션한다. 예를 들어 아래 규칙은 + /~user를 기준이 되는 /u/user로 + 대체하고, /u/user 마지막에 슬래쉬가 없다면 + 추가한다.

+ +
+RewriteRule   ^/~([^/]+)/?(.*)    /u/$1/$2  [R]
+RewriteRule   ^/([uge])/([^/]+)$  /$1/$2/   [R]
+
+
+
+ + + +

기준이 되는 호스트명

+ + + +
+
상황설명:
+ +
...
+ +
해결책:
+ +
+
+RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
+RewriteCond %{HTTP_HOST}   !^$
+RewriteCond %{SERVER_PORT} !^80$
+RewriteRule ^/(.*)         http://fully.qualified.domain.name:%{SERVER_PORT}/$1 [L,R]
+RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
+RewriteCond %{HTTP_HOST}   !^$
+RewriteRule ^/(.*)         http://fully.qualified.domain.name/$1 [L,R]
+
+
+
+ + + +

DocumentRoot를 옮긴 경우

+ + + +
+
상황설명:
+ +
+

웹서버의 DocumentRoot는 보통 URL + "/"과 직접 관련있다. 그러나 이곳에 모든 + 자료가 있지 않고, 자료가 다른 여러 곳에 흩어져있는 + 경우가 있다. 예를 들어 인트라넷 사이트에 (외부를 위한 + 홈페이지) /e/www/와 (인트라넷을 위한 + 홈페이지) /e/sww/가 있다고 하자. 이제 + DocumentRoot가 + /e/www/이기때문에, 요청에서 페이지에 + 포함된 그림 등을 이곳에서 가져와야 한다.

+
+ +
해결책:
+ +
+

우리는 URL /를 /e/www/로 + 리다이렉션만 하면 된다. 사소해 보이지만 실제로 + mod_rewrite를 사용해서만 가능하다. + (mod_alias 등이 제공하는) URL + Alias 같은 전형적인 방법은 앞부분만 + 찾는다. DocumentRoot가 + 모든 URL의 앞부분이기때문에 이 방법을 사용하여 리다이렉션을 + 할 수 없다. mod_rewrite를 사용하면 + 진짜 간단하다:

+ +
+RewriteEngine on
+RewriteRule   ^/$  /e/www/  [R]
+
+
+
+ + + +

마지막 슬래쉬 문제

+ + + +
+
상황설명:
+ +
+

디렉토리를 지칭하는 URL의 마지막 슬래쉬 문제가 + 없다면 모든 웹관리자는 환호할 것이다. 슬래쉬가 없다면, + 즉 /~quux/foo/ 대신 /~quux/foo를 + 사용하면 서버가 foo라는 파일을 + 찾기때문에 오류가 발생한다. 파일이 디렉토리이기때문에 + 받아들이지 않는다. 대부분의 경우 보통 서버가 자동으로 + URL을 고치지만, 가끔 직접 해줘야 할 경우가 있다. 예를 + 들어, CGI 스크립트 등으로 복잡한 URL 재작성을 한 후에 + 그러하다.

+
+ +
해결책:
+ +
+

이 미묘한 문제의 해결방법은 서버가 자동으로 마지막 + 슬래쉬를 추가하는 것이다. 브라우저가 나머지 그림 등을 + 올바로 요청할 수 있도록, 외부 리다이렉션을 해야 한다. + 내부 리다이렉션을 한다면 디렉토리 페이지에만 동작하여 + 이 페이지가 상대 URL로 포함하는 그림을 브라우저가 + 요청할때 찾을 수 없다. 예를 들어, 외부 리다이렉션을 + 사용하지 않을때 /~quux/foo/index.html에서 + image.gif를 요청하면 + /~quux/image.gif를 요청하게 된다!

+ +

그래서 이를 해결하기위해 다음과 같이 설정한다:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo$  foo/  [R]
+
+ +

홈디렉토리의 최상위 .htaccess 파일에 + 다음과 같이 설정할 수도 있다. 그러나 처리하는데 부담이 + 된다.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteCond    %{REQUEST_FILENAME}  -d
+RewriteRule    ^(.+[^/])$           $1/  [R]
+
+
+
+ + + +

일관된 URL 구조로 만든 웹클러스터

+ + + +
+
상황설명:
+ +
+

인트라넷 웹서버군의 모든 웹서버에 동일하고 일관된 + URL 구조를 만들고 싶다. 즉, 모든 (정의상 서버에 속하여 + 서버에 의존적인!) URL을 서버 독립적으로 만든다! + 웹 이름공간에 서버독립적인 동일한 구조를 부여해야 한다: + URL은 실제 서버를 지칭하면 안된다. 서버군이 자동으로 + 실제 서버로 유도한다.

+
+ +
해결책:
+ +
+

먼저 사용자, 그룹, 독립체의 위치 정보를 저장한 + (분산된) 외부맵에 실제 서버 정보를 얻어온다. 외부맵은 + 다음과 같은 형식이다

+ +
+user1  server_of_user1
+user2  server_of_user2
+:      :
+
+ +

우리는 이 정보를 각각 map.xxx-to-host + 파일에 저장했다. 다음으로 모든 서버에서 URL이 서버에 + 없다면 다음과 같은 URL을,

+ +
+/u/user/anypath
+/g/group/anypath
+/e/entity/anypath
+
+ +

다음과 같이 리다이렉션한다

+ +
+http://physical-host/u/user/anypath
+http://physical-host/g/group/anypath
+http://physical-host/e/entity/anypath
+
+ +

아래 규칙은 맵파일을 사용하여 이 작업을 한다 (server0은 + 맵에 항목이 없는 경우 사용할 기본서버라고 가정한다):

+ +
+RewriteEngine on
+
+RewriteMap      user-to-host   txt:/path/to/map.user-to-host
+RewriteMap     group-to-host   txt:/path/to/map.group-to-host
+RewriteMap    entity-to-host   txt:/path/to/map.entity-to-host
+
+RewriteRule   ^/u/([^/]+)/?(.*)   http://${user-to-host:$1|server0}/u/$1/$2
+RewriteRule   ^/g/([^/]+)/?(.*)  http://${group-to-host:$1|server0}/g/$1/$2
+RewriteRule   ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2
+
+RewriteRule   ^/([uge])/([^/]+)/?$          /$1/$2/.www/
+RewriteRule   ^/([uge])/([^/]+)/([^.]+.+)   /$1/$2/.www/$3\
+
+
+
+ + + +

홈디렉토리를 다른 웹서버로 이전

+ + + +
+
상황설명:
+ +
+

많은 웹관리자는 웹서버의 모든 홈디렉토리를 다른 + 웹서버로 이전한 경우 해결책을 물어본다. 이 방법은 + 이전 서버를 대체할 새로운 서버를 구성하는데 시간이 + 걸리는 경우에 필요하다.

+
+ +
해결책:
+ +
+

mod_rewrite를 사용하면 간단하다. + 이전 웹서버는 모든 /~user/anypath URL을 + http://newserver/~user/anypath로 + 리다이렉션하면 된다.

+ +
+RewriteEngine on
+RewriteRule   ^/~(.+)  http://newserver/~$1  [R,L]
+
+
+
+ + + +

홈디렉토리 구조 만들기

+ + + +
+
상황설명:
+ +
+

사용자가 수천명인 사이트는 보통 홈디렉토리 구조를 + 만든다. 즉, 예를 들어 이름이 사용자명의 첫번째 문자인 + 하위디렉토리에 홈디렉토리를 둔다. 그래서, + /~foo/anypath는 + /home/f/foo/.www/anypath이고, + /~bar/anypath는 + /home/b/bar/.www/anypath이다.

+
+ +
해결책:
+ +
+

물결표시가 있는 URL을 위와 같은 구조로 변환하기위해 + 다음 규칙을 사용한다.

+ +
+RewriteEngine on
+RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3
+
+
+
+ + + +

파일시스템 재구성

+ + + +
+
상황설명:
+ +
+

이 예는 실로 하드코어적이다: 디렉토리별 + RewriteRules를 매우 많이 사용하여 자료 + 자체는 그대로 둔체로 웹에 자료를 자연스럽게 브라우징하도록 + 한다. 배경: 나는 1992년 부터 자유롭게 사용할 수 있는 + 유닉스 소프트웨어들을 net.sw에 + 모아두고 있었다. 이는 내가 컴퓨터과학을 공부하면서 + 여러해동안 여가시간에 시스템 관리자와 네트웍 관리자를 + 해왔기때문에 내 취미이자 일이다. 매주마다 새로 소프트웨어가 + 추가될 때마다 디렉토리를 깊게 만들어왔다:

+ +
+drwxrwxr-x   2 netsw  users    512 Aug  3 18:39 Audio/
+drwxrwxr-x   2 netsw  users    512 Jul  9 14:37 Benchmark/
+drwxrwxr-x  12 netsw  users    512 Jul  9 00:34 Crypto/
+drwxrwxr-x   5 netsw  users    512 Jul  9 00:41 Database/
+drwxrwxr-x   4 netsw  users    512 Jul 30 19:25 Dicts/
+drwxrwxr-x  10 netsw  users    512 Jul  9 01:54 Graphic/
+drwxrwxr-x   5 netsw  users    512 Jul  9 01:58 Hackers/
+drwxrwxr-x   8 netsw  users    512 Jul  9 03:19 InfoSys/
+drwxrwxr-x   3 netsw  users    512 Jul  9 03:21 Math/
+drwxrwxr-x   3 netsw  users    512 Jul  9 03:24 Misc/
+drwxrwxr-x   9 netsw  users    512 Aug  1 16:33 Network/
+drwxrwxr-x   2 netsw  users    512 Jul  9 05:53 Office/
+drwxrwxr-x   7 netsw  users    512 Jul  9 09:24 SoftEng/
+drwxrwxr-x   7 netsw  users    512 Jul  9 12:17 System/
+drwxrwxr-x  12 netsw  users    512 Aug  3 20:15 Typesetting/
+drwxrwxr-x  10 netsw  users    512 Jul  9 14:08 X11/
+
+ +

1996년 7월 이 저장소를 멋있는 웹 인터페이스를 통해 + 세상에 공개하기로 결정햇다. "멋있다"는 말은, 최상위 + 디렉토리에 CGI 스크립트를 두지 않고도, 저장소 계층구조를 + 직접 브라우질하길 바란다는 뜻이다. 왜? 저장소를 나중에 + FTP로도 접근할 수 있도록 만들 예정이였기때문에 웹이나 + CGI와 관련된 내용을 같이 두기 싫었다.

+
+ +
해결책:
+ +
+

해결책은 두 부분으로 나뉜다: 먼저 디렉토리 수준에서 + 필요한 모든 페이지를 동적으로 만드는 CGI 스크립트가 + 필요하다. 나는 이 스크립트들을 다음과 같이 + /e/netsw/.www/에 두었다:

+ +
+-rw-r--r--   1 netsw  users    1318 Aug  1 18:10 .wwwacl
+drwxr-xr-x  18 netsw  users     512 Aug  5 15:51 DATA/
+-rw-rw-rw-   1 netsw  users  372982 Aug  5 16:35 LOGFILE
+-rw-r--r--   1 netsw  users     659 Aug  4 09:27 TODO
+-rw-r--r--   1 netsw  users    5697 Aug  1 18:01 netsw-about.html
+-rwxr-xr-x   1 netsw  users     579 Aug  2 10:33 netsw-access.pl
+-rwxr-xr-x   1 netsw  users    1532 Aug  1 17:35 netsw-changes.cgi
+-rwxr-xr-x   1 netsw  users    2866 Aug  5 14:49 netsw-home.cgi
+drwxr-xr-x   2 netsw  users     512 Jul  8 23:47 netsw-img/
+-rwxr-xr-x   1 netsw  users   24050 Aug  5 15:49 netsw-lsdir.cgi
+-rwxr-xr-x   1 netsw  users    1589 Aug  3 18:43 netsw-search.cgi
+-rwxr-xr-x   1 netsw  users    1885 Aug  1 17:41 netsw-tree.cgi
+-rw-r--r--   1 netsw  users     234 Jul 30 16:35 netsw-unlimit.lst
+
+ +

DATA/ 하위디렉토리에 위에서 말한 저장소가 + 있다. 실제 net.sw의 내용은 보통 + rdist를 사용하여 자동으로 가져온다. 두번째 + 부분이 남았다: 어떻게 이 두 구조를 하나의 자연스러운 + URL 구조로 연결하는가? 사용자에게 DATA/ + 디렉토리를 감추고, URL마다 적절한 CGI 스크립트를 실행하고 + 싶다. 해결책은 다음과 같다: 먼저 서버의 DocumentRoot에서 공개된 + URL /net.sw/를 내부 경로 /e/netsw로 + 재작성하기위해 디렉토리별 설정파일에 다음과 같이 설정한다:

+ +
+RewriteRule  ^net.sw$       net.sw/        [R]
+RewriteRule  ^net.sw/(.*)$  e/netsw/$1
+
+ +

첫번째 규칙은 마지막에 슬래쉬가 없는 요청을 위해서 + 사용했다! 두번째 규칙이 실제 작업을 한다. 그리고 디렉토리별 + 설정파일 /e/netsw/.www/.wwwacl에 결정적인 + 설정이 나온다:

+ +
+Options       ExecCGI FollowSymLinks Includes MultiViews
+
+RewriteEngine on
+
+#  앞 부분이 /net.sw/ 로 접근한다
+RewriteBase   /net.sw/
+
+#  먼저 최상위 디렉토리를
+#  cgi 스크립트로 재작성한다
+RewriteRule   ^$                       netsw-home.cgi     [L]
+RewriteRule   ^index\.html$            netsw-home.cgi     [L]
+
+#  브라우저가 디렉토리별 페이지를 요청한 경우
+#  하위디렉토리를 추출한다
+RewriteRule   ^.+/(netsw-[^/]+/.+)$    $1                 [L]
+
+#  이제 재작성을 마친다
+RewriteRule   ^netsw-home\.cgi.*       -                  [L]
+RewriteRule   ^netsw-changes\.cgi.*    -                  [L]
+RewriteRule   ^netsw-search\.cgi.*     -                  [L]
+RewriteRule   ^netsw-tree\.cgi$        -                  [L]
+RewriteRule   ^netsw-about\.html$      -                  [L]
+RewriteRule   ^netsw-img/.*$           -                  [L]
+
+#  다른 cgi 스크립트가 처리할
+#  하위디렉토리가 남았다
+RewriteRule   !^netsw-lsdir\.cgi.*     -                  [C]
+RewriteRule   (.*)                     netsw-lsdir.cgi/$1
+
+ +

해석을 위한 힌트:

+ +
    +
  1. 네번째 부분에서 대체 필드('-')가 + 없고 L (last) 플래그가 있음을 주목하라
    2. + +
  2. 마지막 부분에서 첫번째 규칙에 ! + (not) 문자와 C (chain) 플래그를 주목하라
    3. + +
  3. 마지막 규칙에서 기타 해당하지 않는 모든 경우를 + 잡아내는 패턴을 주목하라
    4. +
+
+
+ + + +

NCSA imagemap을 아파치 mod_imap으로

+ + + +
+
상황설명:
+ +
+

사람들은 NCSA 웹서버에서 현대적인 아파치 웹서버로 + 자연스럽게 옮겨가길 바란다. 그래서 오래된 NCSA + imagemap 프로그램을 사용한 페이지를 현대적인 + 아파치 mod_imap로 처리하길 바란다. + 문제는 imagemap 프로그램을 + /cgi-bin/imagemap/path/to/page.map과 + 같이 참조하는 하이퍼링크가 많다는 것이다. 아파치는 + /path/to/page.map과 같은 요청을 받아야 + 한다.

+
+ +
해결책:
+ +
+

모든 요청에서 앞부분을 동적으로 제거하는 전역 규칙을 + 사용한다:

+ +
+RewriteEngine  on
+RewriteRule    ^/cgi-bin/imagemap(.*)  $1  [PT]
+
+
+
+ + + +

여러 디렉토리에서 페이지 검색

+ + + +
+
상황설명:
+ +
+

가끔 웹서버가 여러 디렉토리에서 파일을 찾아야 할 + 때가 있다. 이 경우 MultiViews나 다른 방법은 도움이 + 안된다.

+
+ +
해결책:
+ +
+

여러 디렉토리에서 파일을 찾는 규칙을 직접 프로그램한다.

+ +
+RewriteEngine on
+
+#   먼저 custom/에서 찾길 시도하고...
+#   ...찾으면 끝!
+RewriteCond         /your/docroot/dir1/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir1/$1  [L]
+
+#   두번째로 pub/에서 찾길 시도한다...
+#   ...찾으면 끝!
+RewriteCond         /your/docroot/dir2/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir2/$1  [L]
+
+#   못찾으면 다른 Alias나 ScriptAlias 지시어 등으로 진행한다.
+RewriteRule   ^(.+)  -  [PT]
+
+
+
+ + + +

URL에 따라 환경변수를 설정한다

+ + + +
+
상황설명:
+ +
+

요청들간에 상태정보를 유지하기위해 URL에 정보를 + 인코딩하는 방법도 있다. 그러나 단지 이 정보를 제거하기위해 + 모든 페이지에 CGI wrapper를 사용하고 싶지 않다.

+
+ +
해결책:
+ +
+

재작성 규칙을 사용하여 상태정보를 추출하고, 추출한 + 정보를 나중에 XSSI나 CGI에서 사용하기위해 환경변수에 + 저장한다. 그래서 URL /foo/S=java/bar/는 + /foo/bar/로 변환되고 STATUS라는 + 환경변수 값을 "java"로 설정한다.

+ +
+RewriteEngine on
+RewriteRule   ^(.*)/S=([^/]+)/(.*)    $1/$3 [E=STATUS:$2]
+
+
+
+ + + +

가상 사용자 호스트

+ + + +
+
상황설명:
+ +
+

가상호스트를 사용하지 않고 같은 컴퓨터로 DNS A + 레코드를 설정하여 + www.username.host.domain.com을 + 사용자의 홈페이지로 제공하고 싶다.

+
+ +
해결책:
+ +
+

HTTP/1.0 요청의 경우 방법이 없지만, Host: HTTP + 헤더를 포함한 HTTP/1.1 요청은 다음 규칙을 사용하여 + 내부적으로 http://www.username.host.com/anypath를 + /home/username/anypath로 재작성할 수 + 있다:

+ +
+RewriteEngine on
+RewriteCond   %{HTTP_HOST}                 ^www\.[^.]+\.host\.com$
+RewriteRule   ^(.+)                        %{HTTP_HOST}$1          [C]
+RewriteRule   ^www\.([^.]+)\.host\.com(.*) /home/$1$2
+
+
+
+ + + +

홈디렉토리를 외부 서버로 리다이렉션

+ + + +
+
상황설명:
+ +
+

지역 도메인 ourdomain.com 밖에서 요청이 + 들어오면 홈디렉토리 URL을 다른 웹서버 + www.somewhere.com으로 리다리렉션하길 + 바란다. 종종 가상호스트 사용장소에서 사용한다.

+
+ +
해결책:
+ +
+

재작성 조건을 사용하면 된다:

+ +
+RewriteEngine on
+RewriteCond   %{REMOTE_HOST}  !^.+\.ourdomain\.com$
+RewriteRule   ^(/~.+)         http://www.somewhere.com/$1 [R,L]
+
+
+
+ + + +

실패한 URL을 다른 웹서버로 리다이렉션

+ + + +
+
상황설명:
+ +
+

URL 재작성에 대해서 웹서버 A에 해당 파일이 없는 + 경우 웹서버 B로 요청을 리다이렉션하는 방법을 자주 + 물어본다. 보통 Perl로 작성한 ErrorDocument CGI 스크립트를 + 사용하지만, mod_rewrite를 사용하는 + 방법도 있다. 그러나 성능은 ErrorDocument CGI 스크립트보다 + 떨어짐을 명심하라!

+
+ +
해결책:
+ +
+

첫번째 방법은 빠르지만 유연성이 떨어지고 완전하지 + 않다:

+ +
+RewriteEngine on
+RewriteCond   /your/docroot/%{REQUEST_FILENAME} !-f
+RewriteRule   ^(.+)                             http://webserverB.dom/$1
+
+ +

이 방법의 단점은 DocumentRoot 안에 있는 페이지만 + 가능하다는 점이다. (예를 들어 홈디렉토리 등을 위해) + 조건을 추가할 수 있지만, 더 좋은 방법이 있다:

+ +
+RewriteEngine on
+RewriteCond   %{REQUEST_URI} !-U
+RewriteRule   ^(.+)          http://webserverB.dom/$1
+
+ +

mod_rewrite의 URL 전방참조(look-ahead)를 + 사용한다. 그래서 모든 URL에 동작하고 안전하다. 그러나 + 모든 요청마다 내부 하위요청을 한번 더 하기때문에 웹서버 + 성능에 악영향을 준다. 그래서 강력한 CPU에서 웹서버를 + 실행한다면 사용하라. 컴퓨터가 느리다면 첫번째 방법이나 + 더 나은 ErrorDocument + CGI 스크립트를 사용하라.

+
+
+ + + +

확장 리다이렉션

+ + + +
+
상황설명:
+ +
+

가끔 리다이렉션하는 URL을 더 조절할 필요가 있다. + 아파치 내부 URL escape 함수는 "url#anchor" + 같은 URL의 anchor도 escape한다. 아파치의 + uri_escape() 함수는 우물정자(#)도 같이 + escape하므로 사용할 수 없다. 그러면 어떻게 이런 URL로 + 리다이렉션할 수 있나?

+
+ +
해결책:
+ +
+

직접 리다이렉션하는 NPH-CGI 스크립트를 사용한 해결책이 + 필요하다. escape를 하지 않기때문이다 (NPH=non-parseable + headers). 먼저 다음 서버설정을 하여 (재작성 규칙의 + 끝부분에 사용해야 한다) 새로운 URL scheme + xredirect:를 도입한다:

+ +
+RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
+            [T=application/x-httpd-cgi,L]
+
+ +

그러면 xredirect:로 시작하는 모든 URL은 + nph-xredirect.cgi 프로그램을 통하게 된다. + 프로그램은 다음과 같다:

+ +
+#!/path/to/perl
+##
+##  nph-xredirect.cgi -- NPH/CGI script for extended redirects
+##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+
+$| = 1;
+$url = $ENV{'PATH_INFO'};
+
+print "HTTP/1.0 302 Moved Temporarily\n";
+print "Server: $ENV{'SERVER_SOFTWARE'}\n";
+print "Location: $url\n";
+print "Content-type: text/html\n";
+print "\n";
+print "<html>\n";
+print "<head>\n";
+print "<title>302 Moved Temporarily (EXTENDED)</title>\n";
+print "</head>\n";
+print "<body>\n";
+print "<h1>Moved Temporarily (EXTENDED)</h1>\n";
+print "The document has moved <a HREF=\"$url\">here</a>.<p>\n";
+print "</body>\n";
+print "</html>\n";
+
+##EOF##
+
+ +

그러면 mod_rewrite가 직접 받지못하는 + 모든 URL scheme으로 리다이렉션할 수 있다. 예를 들어, + 다음과 같이 news:newsgroup으로 리다이렉션할 + 수 있다

+ +
+RewriteRule ^anyurl  xredirect:news:newsgroup
+
+ +
주의: 위의 특별한 "통과" 규칙을 사용하여 + xredirect:를 마지막에 확장해야 하기때문에 + 규칙에 [R]이나 [R,L]을 사용하면 + 안된다.
+
+
+ + + +

저장소 접근 중계(multiplexer)

+ + + +
+
상황설명:
+ +
+

http://www.perl.com/CPAN에 + 있는 대단한 CPAN (Comprehensive Perl Archive Network)을 + 아는가? 이 주소는 세계에 흩어진 여러 CPAN 미러 FTP + 서버중 클라이언트에 가까이 있는 서버로 리다이렉션한다. + 이를 FTP 접근 중계 서비스라고 한다. CPAN은 CGI 스크립트를 + 사용하지만, mod_rewrite를 사용하여 + 비슷하게 만들 수 있을까?

+
+ +
해결책:
+ +
+

먼저 mod_rewrite 3.0.0 버전부터 + 리다이렉션에 "ftp:" scheme을 사용할 수 + 있다. 다음으로 클라이언트의 최상위 도메인을 RewriteMap과 같이 + 사용하여 위치를 추정할 수 있다. 복잡히 엮인 규칙에서 + 최상위 도메인을 중계맵의 키로 사용한다.

+ +
+RewriteEngine on
+RewriteMap    multiplex                txt:/path/to/map.cxan
+RewriteRule   ^/CxAN/(.*)              %{REMOTE_HOST}::$1                 [C]
+RewriteRule   ^.+\.([a-zA-Z]+)::(.*)$  ${multiplex:$1|ftp.default.dom}$2  [R,L]
+
+ +
+##
+##  map.cxan -- Multiplexing Map for CxAN
+##
+
+de        ftp://ftp.cxan.de/CxAN/
+uk        ftp://ftp.cxan.uk/CxAN/
+com       ftp://ftp.cxan.com/CxAN/
+ :
+##EOF##
+
+
+
+ + + +

시간에 따른 재작성

+ + + +
+
상황설명:
+ +
+

시간에 따라 다른 내용을 서비스하는 경우 많은 웹관리자는 + 잠시 특별한 페이지로 리다이렉션하기위해 CGI 스크립트를 + 사용한다. mod_rewrite로는 어떻게 + 할 수 있는가?

+
+ +
해결책:
+ +
+

재작성 조건에서 사용할 수 있는 여러 TIME_xxx + 변수가 있다. 변수와 특별한 사전순서 비교 + <STRING, >STRING, + =STRING을 사용하여 시간에 따라 리다이렉션할 + 수 있다:

+ +
+RewriteEngine on
+RewriteCond   %{TIME_HOUR}%{TIME_MIN} >0700
+RewriteCond   %{TIME_HOUR}%{TIME_MIN} <1900
+RewriteRule   ^foo\.html$             foo.day.html
+RewriteRule   ^foo\.html$             foo.night.html
+
+ +

URL foo.html을 요청하면 + 07:00-19:00 동안 foo.day.html + 내용을 서비스하고, 나머지 시간 동안 + foo.night.html 내용을 서비스한다. 홈페이지에서 + 사용하기 좋은 기능이다...

+
+
+ + + +

YYYY를 XXXX로 이전한 경우 역호환

+ + + +
+
상황설명:
+ +
+

여러 .html 파일을 .phtml로 + 변환하는 등 document.YYYY를 + document.XXXX로 이전한후 역호환(backward + compatibility) URL을 (가상적으로 존재하게) 만들 수 + 있나?

+
+ +
해결책:
+ +
+

이름을 기본이름으로 재작성한후 새로운 확장자를 + 가진 파일이 있는지 검사한다. 있다면 그 파일명을 사용하고, + 없으면 URL을 원래 상태로 재작성한다.

+ + +
+#   문서.html 이 없고
+#   문서.phtml 만 있는 경우
+#   문서.html 을 문서.phtml 로
+#   재작성하는 역호환 규칙
+RewriteEngine on
+RewriteBase   /~quux/
+#   기본이름을 찾고, 찾았다는 사실을 기억한다
+RewriteRule   ^(.*)\.html$              $1      [C,E=WasHTML:yes]
+#   파일이 있다면 문서.phtml 로 재작성한다
+RewriteCond   %{REQUEST_FILENAME}.phtml -f
+RewriteRule   ^(.*)$ $1.phtml                   [S=1]
+#   아니면 앞에서 찾은 기본이름을 되돌린다
+RewriteCond   %{ENV:WasHTML}            ^yes$
+RewriteRule   ^(.*)$ $1.html
+
+
+
+ + + +
top
+
+

컨텐츠 다루기

+ + + +

새로 이전 (감추기)

+ + + +
+
상황설명:
+ +
+

최근 foo.html을 bar.html로 + 변경하고 역호환성을 위해 이전 URL을 계속 제공하고 + 싶다고 가정하자. 사용자는 이전 URL이 변경되었다는 + 사실을 눈치채지 못한다.

+
+ +
해결책:
+ +
+

다음 규칙으로 이전 URL을 내부적으로 새로운 URL로 + 재작성한다:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html
+
+
+
+ + + +

새로 이전 (알리기)

+ + + +
+
상황설명:
+ +
+

다시 foo.html을 bar.html로 + 변경하고 역호환성을 위해 이전 URL을 계속 제공하고 + 싶다고 가정하자. 그러나 이제는 이전 URL을 사용하면 + 사용자에게 새로운 URL을 힌트로 알려준다. 즉, 브라우저 + 주소창이 변한다.

+
+ +
해결책:
+ +
+

새로운 URL로 HTTP 리다이렉션하다. 그러면 브라우저가 + 새로운 URL를 보이고 변경사실을 사용자가 알게된다:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html  [R]
+
+
+
+ + + +

브라우저에 따른 내용

+ + + +
+
상황설명:
+ +
+

최소한 중요한 최상위 페이지는 브라우저에 최적화된 + 내용으로 서비스해야할 경우가 있다. 즉, 최신 Netscape + 브라우저에게는 최상의 버전을, Lynx 브라우저에게는 + 최저 버전을, 나머지 브라우저에는 평균적인 버전을 + 제공한다.

+
+ +
해결책:
+ +
+

브라우저가 내용협상을 위해 자신의 종류에 대한 정보를 + 제공하지 않기때문에 내용협상을 사용할 수 없다. 대신 + HTTP "User-Agent" 헤더를 사용한다. 다음 규칙은 HTTP + "User-Agent" 헤더가 "Mozilla/3"으로 시작하면 + foo.html 페이지를 foo.NS.html로 + 재작성하고 재작성을 중단한다. 브라우저가 "Lynx"나 + "Mozilla" 버전 1 혹은 2라면 URL은 + foo.20.html이 된다. 나머지 브라우저는 + foo.32.html 페이지를 받는다. 아래 규칙이 + 이 작업을 한다:

+ +
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
+RewriteRule ^foo\.html$         foo.NS.html          [L]
+
+RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
+RewriteRule ^foo\.html$         foo.20.html          [L]
+
+RewriteRule ^foo\.html$         foo.32.html          [L]
+
+
+
+ + + +

동적 미러

+ + + +
+
상황설명:
+ +
+

외부 호스트에 우리 사이트로 가져오고 싶은 좋은 + 웹페이지가 있다고 가정하자. FTP 서버의 경우 직접 외부 + 자료의 최신복사본을 유지하는 mirror 프로그램을 + 사용할 수 있고, 웹서버라면 HTTP로 비슷한 작업을 하는 + webcopy 프로그램을 사용할 수 있다. 그러나 + 두 방법 모두 단점이 있다: 복사본은 가끔씩 프로그램을 + 실행해줄 때만 최신판으로 유지된다. 직접 구성해야하는 + 정적인 미러가 아니라면 좋겠다. 대신 (외부 호스트에서 + 자료가 갱신되면) 필요할때 자동으로 자료를 갱신하는 + 동적 미러가 필요하다.

+
+ +
해결책:
+ +
+

이를 위해 Proxy Throughput 기능을 (플래그 + [P]) 사용하여 외부 웹페이지 혹은 외부 + 웹공간 전체를 우리 이름공간으로 대응한다:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^hotsheet/(.*)$  http://www.tstimpreso.com/hotsheet/$1  [P]
+
+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^usa-news\.html$   http://www.quux-corp.com/news/index.html  [P]
+
+
+
+ + + +

동적 역미러

+ + + +
+
상황설명:
+ +
...
+ +
해결책:
+ +
+
+RewriteEngine on
+RewriteCond   /mirror/of/remotesite/$1           -U
+RewriteRule   ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1
+
+
+
+ + + +

없는 자료를 인트라넷에서 가져오기

+ + + +
+
상황설명:
+ +
+

실제 자료를 방화벽이 보호하는 (내부) 인트라넷 웹서버에 + (www2.quux-corp.dom) 저장하면서, 기업의 + (외부) 인터넷 웹서버를 (www.quux-corp.dom) + 실행하는 것처럼 보이게 한다. 외부 웹서버는 요청한 + 자료를 내부 웹서버에서 가져온다.

+
+ +
해결책:
+ +
+

먼저 방화벽이 내부 웹서버를 보호하고 외부 웹서버만이 + 내부 웹서버에서 자료를 얻을 수 있게 한다. 다음과 같이 + 패킷필터링 방화벽을 설정한다:

+ +
+ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
+DENY  Host *                 Port *     --> Host www2.quux-corp.dom Port 80
+
+ +

실제 설정문법에 알맞게 고쳐라. 없는 자료를 내부적으로 + proxy throughput 기능을 통해 요청하는 + mod_rewrite 규칙을 작성한다:

+ +
+RewriteRule ^/~([^/]+)/?(.*)          /home/$1/.www/$2
+RewriteCond %{REQUEST_FILENAME}       !-f
+RewriteCond %{REQUEST_FILENAME}       !-d
+RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
+
+
+
+ + + +

로드밸런싱 (부하 분산하기)

+ + + +
+
상황설명:
+ +
+

www.foo.com의 통신량을 + www[0-5].foo.com (총 서버 6대)으로 분산하고 + 싶다. 어떻게 하는가?

+
+ +
해결책:
+ +
+

매우 다양한 방법으로 이 문제를 해결할 수 있다. + 먼저 DNS를 사용한 잘 알려진 방법을 설명하고, + mod_rewrite를 사용하는 경우를 살펴보자:

+ +
    +
  1. + DNS Round-Robin + +

    가장 간단한 로드밸런싱 방법은 BIND의 + DNS round-robin 방식을 사용하는 것이다. 다음과 + 같이 DNS A(address) 레코드에 + www[0-9].foo.com을 설정한다.

    + +
    +www0   IN  A       1.2.3.1
+www1   IN  A       1.2.3.2
+www2   IN  A       1.2.3.3
+www3   IN  A       1.2.3.4
+www4   IN  A       1.2.3.5
+www5   IN  A       1.2.3.6
+
    + +

    그리고 다음 항목을 추가한다:

    + +
    +www    IN  CNAME   www0.foo.com.
+       IN  CNAME   www1.foo.com.
+       IN  CNAME   www2.foo.com.
+       IN  CNAME   www3.foo.com.
+       IN  CNAME   www4.foo.com.
+       IN  CNAME   www5.foo.com.
+       IN  CNAME   www6.foo.com.
+
    + +

    잘못된 것처럼 보이지만, 실제로 BIND의 + 의도된 기능이다. 이제 www.foo.com을 + 찾으면, BIND는 매번 순서를 조금씩 + 바꿔가며 www0-www6을 반환한다. 그래서 + 클라이언트들을 여러 서버로 분산한다. 그러나 DNS + 검색 결과가 네트웍의 다른 네임서버에 캐쉬되여 + www.foo.com을 찾은 결과가 특정 + wwwN.foo.com이면 클라이언트의 다음 + 요청들도 같은 wwwN.foo.com으로 + 보내지기때문에 완벽한 로드밸런싱 기법이 아님을 + 주의하라. 그러나 크게 보면 요청이 여러 웹서버에 + 분산되므로 효과가 좋다.

    +
    2. + +
  2. + DNS 로드밸런싱 + +

    http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html에 + 있는 lbnamed 프로그램을 사용하여 + 정교한 DNS기반 로드밸런싱을 할 수 있다. DNS가 + 실제 로드밸런싱을 하도록 만드는 여러 도구와 Perl + 5 프로그램이다.

    +
    3. + +
  3. + Proxy Throughput Round-Robin + +

    이 방법은 mod_rewrite와 proxy + throughput 기능을 사용한다. 먼저 DNS에 다음 항목을 + 사용하여 www0.foo.com이 실제 + www.foo.com을 전담하게 한다

    + +
    +www    IN  CNAME   www0.foo.com.
+
    + +

    그리고 www0.foo.com을 프록시전용 + 서버로 변경한다. 즉, URL을 받으면 서버는 내부 + 프록시를 통해 다른 5대 서버중 (www1-www5) + 한대로 보내기만 한다. 이를 위해 먼저 모든 URL을 + 로드밸런싱 스크립트 lb.pl로 보내는 + 규칙을 만든다.

    + +
    +RewriteEngine on
+RewriteMap    lb      prg:/path/to/lb.pl
+RewriteRule   ^/(.+)$ ${lb:$1}           [P,L]
+
    + +

    lb.pl을 작성한다:

    + +
    +#!/path/to/perl
+##
+##  lb.pl -- 로드밸런싱 스크립트
+##
+
+$| = 1;
+
+$name   = "www";     # 기본 호스트명
+$first  = 1;         # 첫번째 서버 (자신이 0이기 때문에, 0을 사용하지 않는다)
+$last   = 5;         # round-robin에서 마지막 서버
+$domain = "foo.dom"; # 도메인명
+
+$cnt = 0;
+while (<STDIN>) {
+    $cnt = (($cnt+1) % ($last+1-$first));
+    $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
+    print "http://$server/$_";
+}
+
+##EOF##
+
    + +
    마지막 주의: 왜 이 방법이 유용한가? + www0.foo.com에 부담이 가지않는가? + 물론, 부담이 된다. 그러나 단순한 proxy throughput + 요청만 하기때문에 괜찮다! 모든 SSI, CGI, ePerl + 등은 전적으로 다른 서버가 처리한다. 이것이 핵심이다.
    +
    4. + +
  4. + 하드웨어/TCP Round-Robin + +

    하드웨어를 사용한 해결책도 있다. Cisco는 TCP/IP + 수준에서 로드밸런싱을 하는 LocalDirector라는 괴물을 + 판다. 실제로는 웹서버군 앞단에 위치하는 일종의 + 회로수준 게이트웨이다. 자금이 충분하고 고성능 + 해결책이 필요하다면 이것을 사용하라.

    +
    5. +
+
+
+ + + +

새로운 MIME-type, 새로운 서비스

+ + + +
+
상황설명:
+ +
+

네트웍에는 멋진 CGI 프로그램들이 많다. 그러나 사용하기 + 번거러워서 많은 웹관리자가 사용하지 않는다. 아파치의 + MIME-type에 따른 Action 핸들러 기능도 CGI 프로그램이 + 특별한 URL을 (정확히 PATH_INFO와 + QUERY_STRINGS) 프로그램의 입력으로 사용하지 + 않을 때만 적절하다. 먼저, 확장자가 (secure CGI를 줄여) + .scgi인 파일을 유명한 cgiwrap + 프로그램으로 처리하기위해 새로운 type을 설정한다. + 문제는 (위에서 본) 일관된 URL 구조를 사용하는 경우 + 사용자 홈디렉토리가 /u/user/foo/bar.scgi같은 + URL인 점이다. cgiwrap는 + /~user/foo/bar.scgi/ 형식의 URL을 + 원하기때문이다. 다음 규칙이 문제를 해결한다:

+ +
+RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
+... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3  [NS,T=application/x-http-cgi]
+
+ +

이제 다른 멋진 프로그램, (URL 하위트리에 대한 + access.log를 출력하는) wwwlog와 + (URL 하위트리에 Glimpse를 실행하는) wwwidx가 + 있다고 가정하자. 우리는 프로그램에게 작업할 대상인 + URL 영역을 알려줘야 한다. 그러나 요청할때마다 항상 + 적어줘야 하기때문에 깔끔하지 않다. 즉, 보통 + /u/user/foo/에 대해 swwidx + 프로그램을 실행한다면 다음과 같은 링크를 사용한다

+ +
+/internal/cgi/user/swwidx?i=/u/user/foo/
+
+ +

깔끔하지 않다. 링크에 영역의 위치와 + CGI 위치를 모두 적어야 하기때문이다. + 영역을 재구성한다면 여러 하이퍼링크를 수정하는데 많은 + 시간이 걸릴 것이다.

+
+ +
해결책:
+ +
+

해결책은 자동으로 적절한 CGI를 실행하는 새로운 + 특별한 URL 형식을 만드는 것이다. 다음과 같이 설정한다:

+ +
+RewriteRule   ^/([uge])/([^/]+)(/?.*)/\*  /internal/cgi/user/wwwidx?i=/$1/$2$3/
+RewriteRule   ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
+
+ +

이제 /u/user/foo/을 검색하는 링크는 + 다음과 같다

+ +
+HREF="*"
+/u/user/foo/* (???)
+
+ +

내부적으로 다음과 같이 자동변환된다

+ +
+/internal/cgi/user/wwwidx?i=/u/user/foo/
+
+ +

같은 방법으로 링크 뒤에 :log를 사용하여 + 접근 로그 CGI 프로그램을 실행할 수 있다.

+
+
+ + + +

정적에서 동적으로

+ + + +
+
상황설명:
+ +
+

어떻게 브라우저와 사용자가 모르게 자연스럽게 정적 + 페이지 foo.html을 동적인 foo.cgi로 + 변경할 수 있나.

+
+ +
해결책:
+ +
+

URL을 CGI 스크립트로 재작성하고, MIME-type을 수정하여 + CGI 스크립트로 실행하게 한다. 그래서 + /~quux/foo.html를 요청하면 내부적으로 + /~quux/foo.cgi를 실행하게 된다.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  foo.cgi  [T=application/x-httpd-cgi]
+
+
+
+ + + +

즉석 컨텐츠 재생성

+ + + +
+
상황설명:
+ +
+

이 방법은 실로 비기이다: 동적으로 페이지를 생성하지만, + 정적으로 페이지를 서비스한다. 즉, 페이지는 순수하게 + (파일시스템에서 읽은 내용을 그대로) 정적 페이지로 + 전달되지만, 없을 경우 웹서버가 동적으로 생성한다. + 그러면 누가 (혹은 cron 작업이) 정적 컨텐츠를 지우지않는 + 한 CGI가 생성한 페이지를 정적으로 서비스한다. 컨텐츠를 + 지우면 내용을 갱신한다.

+
+ +
해결책:
+ +
+ 다음 규칙을 사용한다: + +
+RewriteCond %{REQUEST_FILENAME}   !-s
+RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]
+
+ +

여기서 page.html를 요청할때 + page.html이 없거나 파일크기가 0인 경우 + 내부적으로 page.cgi를 실행한다. 여기서 + 비결은 page.cgi가 일반적인 CGI 스크립트와 + 같이 STDOUT에 출력하고, 추가로 출력을 + page.html 파일에 적는다. 한번 실행한후 + 서버는 page.html의 정보를 보낸다. 웹관리자가 + 강재로 내용을 갱신하고 싶다면, (보통 cron 작업이) + page.html을 지우기만 하면 된다.

+
+
+ + + +

자동으로 새로 고침하는 문서

+ + + +
+
상황설명:
+ +
+

복잡한 웹페이지를 만들때 편집자가 내용을 수정할 + 때마다 자동으로 페이지를 새로 고침하는 웹브라우저가 + 있으면 얼마나 좋을까? 불가능한가?

+
+ +
해결책:
+ +
+

가능하다! MIME multipart 기능과 웹서버 NPH 기능, + mod_rewrite의 URL 조작 능력을 결합하면 + 된다. 먼저, 새로운 URL 기능을 만든다: URL에 + :refresh를 추가하기만 하면 파일시스템에서 + 수정될 때마다 새로 고침한다.

+ +
+RewriteRule   ^(/[uge]/[^/]+/?.*):refresh  /internal/cgi/apache/nph-refresh?f=$1
+
+ +

이제 다음 URL에 접근하면

+ +
+/u/foo/bar/page.html:refresh
+
+ +

다음 URL을 내부적으로 부른다

+ +
+/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
+
+ +

이제 NPH-CGI 스크립트만 남았다. 보통 "독자에게 + 연습으로 남겨둠"이라고 말하지만 ;-) 나는 이것도 제공한다.

+ +
+#!/sw/bin/perl
+##
+##  nph-refresh -- NPH/CGI script for auto refreshing pages
+##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+$| = 1;
+
+#   split the QUERY_STRING variable
+@pairs = split(/&/, $ENV{'QUERY_STRING'});
+foreach $pair (@pairs) {
+    ($name, $value) = split(/=/, $pair);
+    $name =~ tr/A-Z/a-z/;
+    $name = 'QS_' . $name;
+    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
+    eval "\$$name = \"$value\"";
+}
+$QS_s = 1 if ($QS_s eq '');
+$QS_n = 3600 if ($QS_n eq '');
+if ($QS_f eq '') {
+    print "HTTP/1.0 200 OK\n";
+    print "Content-type: text/html\n\n";
+    print "&lt;b&gt;ERROR&lt;/b&gt;: No file given\n";
+    exit(0);
+}
+if (! -f $QS_f) {
+    print "HTTP/1.0 200 OK\n";
+    print "Content-type: text/html\n\n";
+    print "&lt;b&gt;ERROR&lt;/b&gt;: File $QS_f not found\n";
+    exit(0);
+}
+
+sub print_http_headers_multipart_begin {
+    print "HTTP/1.0 200 OK\n";
+    $bound = "ThisRandomString12345";
+    print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
+    &print_http_headers_multipart_next;
+}
+
+sub print_http_headers_multipart_next {
+    print "\n--$bound\n";
+}
+
+sub print_http_headers_multipart_end {
+    print "\n--$bound--\n";
+}
+
+sub displayhtml {
+    local($buffer) = @_;
+    $len = length($buffer);
+    print "Content-type: text/html\n";
+    print "Content-length: $len\n\n";
+    print $buffer;
+}
+
+sub readfile {
+    local($file) = @_;
+    local(*FP, $size, $buffer, $bytes);
+    ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
+    $size = sprintf("%d", $size);
+    open(FP, "&lt;$file");
+    $bytes = sysread(FP, $buffer, $size);
+    close(FP);
+    return $buffer;
+}
+
+$buffer = &readfile($QS_f);
+&print_http_headers_multipart_begin;
+&displayhtml($buffer);
+
+sub mystat {
+    local($file) = $_[0];
+    local($time);
+
+    ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
+    return $mtime;
+}
+
+$mtimeL = &mystat($QS_f);
+$mtime = $mtime;
+for ($n = 0; $n &lt; $QS_n; $n++) {
+    while (1) {
+        $mtime = &mystat($QS_f);
+        if ($mtime ne $mtimeL) {
+            $mtimeL = $mtime;
+            sleep(2);
+            $buffer = &readfile($QS_f);
+            &print_http_headers_multipart_next;
+            &displayhtml($buffer);
+            sleep(5);
+            $mtimeL = &mystat($QS_f);
+            last;
+        }
+        sleep($QS_s);
+    }
+}
+
+&print_http_headers_multipart_end;
+
+exit(0);
+
+##EOF##
+
+
+
+ + + +

대량의 가상호스트

+ + + +
+
상황설명:
+ +
+

가상호스트가 몇개만 있다면 아파치의 <VirtualHost> + 기능이 잘 동작한다. 그러나 가상호스트가 수백개 있는 + ISP라면 이 기능이 최선은 아니다.

+
+ +
해결책:
+ +
+

이 기능을 제공하려면 Proxy Throughput + 기능을 (플래그 [P]) 사용하여 외부 웹페이지 + 혹은 전체 외부 웹영역을 우리의 이름공간에 대응한다:

+ +
+##
+##  vhost.map
+##
+www.vhost1.dom:80  /path/to/docroot/vhost1
+www.vhost2.dom:80  /path/to/docroot/vhost2
+     :
+www.vhostN.dom:80  /path/to/docroot/vhostN
+
+ +
+##
+##  httpd.conf
+##
+    :
+#   리다이렉트할때 정규 호스트명을 사용한다.
+UseCanonicalName on
+
+    :
+#   가상호스트를 CLF 형식 앞에 추가한다
+CustomLog  /path/to/access_log  "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
+    :
+
+#   주서버에서 재작성 엔진을 사용한다
+RewriteEngine on
+
+#   두 맵을 정의한다: 하나는 URL을 고치고,
+#   다른 하나는 가상호스트별 DocumentRoot를
+#   정의한다.
+RewriteMap    lowercase    int:tolower
+RewriteMap    vhost        txt:/path/to/vhost.map
+
+#   이제 크고 복잡한 규칙 한개를 사용하여
+#   가상호스트로 대응한다.
+#
+#   1. 가상호스트들이 같이 사용하는 위치는 대응하지 않는다
+RewriteCond   %{REQUEST_URL}  !^/commonurl1/.*
+RewriteCond   %{REQUEST_URL}  !^/commonurl2/.*
+    :
+RewriteCond   %{REQUEST_URL}  !^/commonurlN/.*
+#
+#   2. 우리가 현재 사용하는 방법이 Host 헤더를
+#      가상호스트를 지원하므로
+#      Host 헤더가 있는지 확인한다
+RewriteCond   %{HTTP_HOST}  !^$
+#
+#   3. 호스트명을 소문자로 만든다
+RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
+#
+#   4. vhost.map에서 호스트명을 찾고
+#      경로일때만 기억한다
+#      (위에서 "NONE"은 아니다)
+RewriteCond   ${vhost:%1}  ^(/.*)$
+#
+#   5. 마지막으로 URL을 문서 위치로 대응하고
+#      로그에 남기기위해 가상호스트를 기억해 둔다
+RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]
+    :
+
+
+
+ + + +
top
+
+

접근 제한

+ + + +

로봇 막기

+ + + +
+
상황설명:
+ +
+

어떻게 하면 특정 웹공간의 페이지를 긁어모으는 귀찮은 + 로봇을 막을 수 있나? "Robot Exclusion Protocol" 항목을 + 저장한 /robots.txt 파일은 보통 이런 로봇을 + 막는데 충분하지 않다.

+
+ +
해결책:
+ +
+

(아마도 디렉토리가 깊어서 로봇이 돌아다니면 서버에 + 부담이 큰 경우) 웹공간 /~quux/foo/arc/에 + 있는 URL들을 거부하는 규칙을 사용한다. 우리는 특정 + 로봇의 접근을 막아야 한다. 즉, 로봇을 실행하는 호스트를 + 막는 것으로는 불충분하며, 그 호스트의 사용자도 막아버리게 + 된다. User-Agent HTTP 헤더 정보도 비교한다.

+ +
+RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*
+RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
+RewriteRule ^/~quux/foo/arc/.+   -   [F]
+
+
+
+ + + +

그림 퍼가기 방지

+ + + +
+
상황설명:
+ +
+

http://www.quux-corp.de/~quux/에 있는 + 페이지들이 GIF 그림을 포함한다고 가정하자. 이 그림이 + 멋있어서, 다른 사람들이 자신의 페이지에 직접 링크를 + 건다. 서버에 불필요한 부담이 되므로 막고 싶다.

+
+ +
해결책:
+ +
+

그림을 100% 보호할 수는 없지만, 최소한 브라우저가 + HTTP Referer 헤더를 보내는 경우 제한할 수 있다.

+ +
+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
+RewriteRule .*\.gif$        -                                    [F]
+
+ +
+RewriteCond %{HTTP_REFERER}         !^$
+RewriteCond %{HTTP_REFERER}         !.*/foo-with-gif\.html$
+RewriteRule ^inlined-in-foo\.gif$   -                        [F]
+
+
+
+ + + +

호스트 거부

+ + + +
+
상황설명:
+ +
+

어떻게 외부에서 서버에 접근할 수 없는 호스트 목록을 + 설정할 수 있나?

+
+ +
해결책:
+ +
+

아파치 >= 1.3b6에서:

+ +
+RewriteEngine on
+RewriteMap    hosts-deny  txt:/path/to/hosts.deny
+RewriteCond   ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
+RewriteCond   ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
+RewriteRule   ^/.*  -  [F]
+
+ +

아파치 <= 1.3b6에서:

+ +
+RewriteEngine on
+RewriteMap    hosts-deny  txt:/path/to/hosts.deny
+RewriteRule   ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1
+RewriteRule   !^NOT-FOUND/.* - [F]
+RewriteRule   ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1
+RewriteRule   !^NOT-FOUND/.* - [F]
+RewriteRule   ^NOT-FOUND/(.*)$ /$1
+
+ +
+##
+##  hosts.deny
+##
+##  주의! 이것은 목록처럼 보이지만 목록이 아니라 맵이다.
+##        mod_rewrite는 이 정보를 키/값 쌍으로 해석하기때문에,
+##        각 항목의 값 자리에 최소한 "-"가 필요하다.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de  -
+192.76.162.40  -
+
+
+
+ + + +

프록시 거부

+ + + +
+
상황설명:
+ +
+

어떻게 특정 호스트 혹은 특정 호스트의 사용자가 + 아파치 프록시를 사용할 수 없도록 하나?

+
+ +
해결책:
+ +
+

먼저 아파치 웹서버를 컴파일할때 구성파일에서 + mod_rewrite가 mod_proxy + 아래에(!) 있어야 한다. 그러면 mod_rewrite는 + mod_proxy 이전에 불린다. + 이제 다음과 같이 특정 호스트를 거부하도록 설정한다...

+ +
+RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+ +

...그리고 다음은 user@host에 따라 거부한다:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}  ^badguy@badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+
+
+ + + +

특별한 인증 방식

+ + + +
+
상활설명:
+ +
+

가끔 매우 특별한 인증이 필요할 때가 있다. 예를 + 들어, 미리 설정해둔 사용자인지 검사한다. 이들에게만 + (mod_auth_basic의 Basic Auth를 사용한 + 경우와 달리) 별다른 물음없이 접근을 허용한다.

+
+ +
해결책:
+ +
+

친구만 접근이 가능하도록 재작성 규칙들을 사용한다:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
+RewriteRule ^/~quux/only-for-friends/      -                                 [F]
+
+
+
+ + + +

Referer기반 변환기(deflector)

+ + + +
+
상황설명:
+ +
+

"Referer" HTTP 헤더에 따라 원하는대로 참조페이지를 + 설정할 수 있는 유연한 URL 변환기를 만들 수 있는가?

+
+ +
해결책:
+ +
+

다음과 같이 복잡한 규칙을...

+ +
+RewriteMap  deflector txt:/path/to/deflector.map
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
+RewriteRule ^.* %{HTTP_REFERER} [R,L]
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
+
+ +

... 재작성 맵과 같이 사용한다:

+ +
+##
+##  deflector.map
+##
+
+http://www.badguys.com/bad/index.html    -
+http://www.badguys.com/bad/index2.html   -
+http://www.badguys.com/bad/index3.html   http://somewhere.com/
+
+ +

그러면 요청을 자동으로 (맵에서 값으로 "-"를 + 사용한 경우) 참조페이지나 (URL이 맵에 있는 경우 두번째 + 아규먼트로) 특정 URL로 리다이렉션한다.

+
+
+ + + +
top
+
+

기타

+ + + +

외부 재작성 엔진

+ + + +
+
상황설명:
+ +
+

FAQ: 어떻게 이런저런 잡다한 문제를 풀 수 있는가? + mod_rewrite로는 해결책이 안보인다...

+
+ +
해결책:
+ +
+

외부 RewriteMap을 사용하라. + 즉, 프로그램이 RewriteMap 역할을 + 한다. 프로그램은 아파치가 시작할때 시작하여 + STDIN에서 요청한 URL을 받고, (같은 순서로!) + 결과 (보통 재작성된) URL을 STDOUT에 출력한다.

+ +
+RewriteEngine on
+RewriteMap    quux-map       prg:/path/to/map.quux.pl
+RewriteRule   ^/~quux/(.*)$  /~quux/${quux-map:$1}
+
+ +
+#!/path/to/perl
+
+#   아파치 서버가 멈추지 않도록
+#   입출력 버퍼를 사용하지 않는다
+$| = 1;
+
+#   stdin에서 한줄씩 URL을 읽고
+#   stdout에 변환한 URL을 출력한다
+while (<>) {
+    s|^foo/|bar/|;
+    print $_;
+}
+
+ +

설명하기위해 모든 /~quux/foo/... URL을 + /~quux/bar/...로 재작성하는 스크립트를 + 예로 들었다. 실제로 마음대로 프로그래밍할 수 있다. + 그러나 일반 사용자가 이런 맵을 사용할 + 수 있다고 하더라고, 오직 시스템 관리자만이 맵을 + 정의해야 함을 주의하라.

+
+
+ + + +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/rewriteguide.xml.ko b/docs/manual/misc/rewriteguide.xml.ko index b2a84babf9..a145f65641 100644 --- a/docs/manual/misc/rewriteguide.xml.ko +++ b/docs/manual/misc/rewriteguide.xml.ko @@ -1,7 +1,7 @@ - + +보안 팁 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Miscellaneous Documentation

보안 팁

+
+

가능한 언어:  en  | + ko 

+
+ +

웹서버를 운영할때 도움이 될 보안 관련 힌트와 팁이다. + 어떤 것은 일반적이고, 어떤 것은 아파치에만 해당하는 것이다.

+
+
+
top
+
+

최신판으로 유지하기

+ +

아파치 웹서버는 안전과 보안 문제에 관심이 많은 개발자 + 공동체로 유명하다. 그러나 크건 작건 발표후 발견되는 문제들을 + 피할 수 없다. 그래서 소프트웨어를 최신버전으로 유지하는 + 것이 중요하다. 아파치에서 직접 웹서버를 다운로드했다면, + 새로운 버전과 보안 업데이트를 알려주는 아파치 + 웹서버 발표 메일링리스트를 구독하길 강력히 권한다. + 아파치 소프트웨어를 배포하는 많은 제삼자들도 비슷한 서비스를 + 제공한다.

+ +

물론 웹서버 코드때문에 웹서버가 공격을 당하는 경우는 + 많지 않다. 그보다 추가 코드, CGI 스크립트, 하위 운영체제의 + 문제로 공격을 당하는 경우가 많다. 그러므로 항상 주의하며 + 시스템의 모든 소프트웨어를 업데이트해야 한다.

+ +
top
+
+

ServerRoot 디렉토리 권한

+ + + +

보통 root 사용자가 아파치를 시작한 후, 요청을 서비스하기위해 + User 지시어로 + 지정한 사용자로 변환한다. root가 실행하는 명령어가 있다면, + root 이외의 사용자가 수정하지 못하도록 주의해야 한다. 이 + 파일들을 root만 쓸 수 있어야 하고, 디렉토리와 모든 상위디렉토리도 + 마찬가지다. 예를 들어, ServerRoot로 /usr/local/apache를 + 사용한다면 root 사용자가 다음과 같이 디렉토리를 만들길 + 제안한다:

+ +

+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs +

+ +

그러면 /, /usr, /usr/local 은 root만이 수정할 수 있다. + httpd 실행파일을 설치할때 다음과 같이 보호해야 한다:

+ +

+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd +

+ +

htdocs 하위디렉토리는 다른 사용자들이 수정할 수 있도록 + 만들 수 있다 -- root는 그곳에 있는 파일을 실행하지도, 만들지도 + 않아야 한다.

+ +

root가 아닌 사용자가 root가 실행하거나 쓰기가능한 파일을 + 수정할 수 있다면 시스템의 root 권한을 훔칠 수 있다. 예를 + 들어, 누군가 httpd 실행파일을 변경하였다면 다음번 시작할때 + 임의의 코드를 실행하게 된다. logs 디렉토리가 (root가 아닌 + 사용자에게) 쓰기가능하다면 누군가 로그파일을 다른 시스템파일로 + 심볼링크를 걸어서 root가 파일에 임의의 자료를 덮어쓸 수 + 있다. 로그파일이 (root가 아닌 사용자에게) 쓰기가능하다면 + 누군가 로그에 이상한 자료를 기록할 수 있다.

+ +
top
+
+

Server Side Includes

+ + + +

Server Side Includes (SSI)는 서버 관리자에게 보안상 몇가지 + 잠재적인 위험이다.

+ +

첫번째 위험은 서버의 부하를 늘리는 점이다. 아파치는 파일에 + SSI 지시어가 있는지 여부와 관계없이 모든 SSI 파일을 분석해야 + 한다. 조금 부하가 늘지만, 서버를 여러 사람이 같이 사용하는 + 환경에서는 심각할 수 있다.

+ +

또, SSI 파일은 일반적인 CGI 스크립트와 동일한 위험을 + 가진다. SSI 파일에서 "exec cmd"를 사용하면 httpd.conf에서 + 아파치를 실행하도록 설정한 사용자와 그룹 권한으로 CGI + 스크립트나 프로그램을 실행할 수 있다.

+ +

장점을 활용하면서 SSI 파일의 보안을 향상시키는 방법이 + 있다.

+ +

SSI 파일이 가져올 수 있는 피해를 격리하기위해 서버관리자는 + 일반적인 CGI 절에서 설명하는 방법으로 + suexec를 사용할 수 있다

+ +

.html이나 .htm 확장자를 SSI 파일로 사용하는 것은 위험하다. + 특히 여러 사람이 공유하거나 통신량이 많은 서버 환경에서 + 위험하다. SSI 파일은 일반적으로 많이 사용하는 .shtml 같은 + 별도의 확장자를 가져야 한다. 그러면 서버 부하를 최소화하고 + 위험요소를 쉽게 관리할 수 있다.

+ +

다른 방법은 SSI 페이지가 스크립트나 프로그램을 실행하지 + 못하도록 만드는 것이다. Options 지시어에서 Includes + 대신 IncludesNOEXEC를 사용한다. 그래도 스크립트가 + ScriptAlias 지시어로 + 지정한 디렉토리에 있다면 <--#include virtual="..." -->를 + 사용하여 CGI 스크립트를 실행할 수 있음을 주의하라.

+ +
top
+
+

일반적인 CGI

+ + + +

결국 당신은 항상 CGI 스크립트/프로그램의 저자를 신뢰해야 + 하고, 고의건 실수이건 CGI의 잠재적인 보안상 허점을 발견할 + 수 있어야 한다. 기본적으로 CGI 스크립트는 웹서버 사용자 + 권한으로 시스템에서 어떤 명령어라도 실행할 수 있기때문에 + 주의있게 확인하지 않으면 매우 위험하다.

+ +

모든 CGI 스크립트가 같은 사용자로 실행되기때문에 다른 + 스크립트와 (고의건 실수이건) 충돌할 가능성이 있다. 예를 + 들어, 사용자 A는 사용자 B를 매우 싫어하여, 사용자 B의 CGI + 데이터베이스를 지워버리는 스크립트를 작성할 수 있다. 아파치 + 1.2 버전부터 포함되었고 아파치 서버에서 특별한 훅(hook)으로 + 동작하는 suEXEC는 스크립트를 + 다른 사용자로 실행하는 방법중 하나다. 다른 대중적인 방법에는 + CGIWrap이 있다.

+ +
top
+
+

ScriptAlias하지 않은 CGI

+ + + +

다음 조건을 만족할때만 사용자가 어떤 디렉토리에서라도 + CGI 스크립트를 실행하도록 허용할 수 있다:

+ + + +
top
+
+

ScriptAlias한 CGI

+ + + +

특정 디렉토리에서만 CGI를 실행할 수 있도록 제한하면 관리자는 + 이들 디렉토리를 통제할 수 있다. 이 경우는 scriptalias하지 + 않은 CGI보다 확실히 안전하다. 단, 신뢰하는 사용자만 디렉토리에 + 접근할 수 있고, 관리자가 새로운 CGI 스크립트/프로그램의 + 잠재적인 보안상 허점을 검사할 용이가 있다면.

+ +

대부분의 사이트는 scriptalias하지 않은 CGI 방식 대신 + 이 방식을 사용한다.

+ +
top
+
+

동적 내용을 생성하는 다른 방법

+ + + +

+ mod_php, mod_perl, mod_tcl, mod_python 같이 서버의 일부로 + 동작하는 임베디드 스크립트는 서버와 같은 사용자로 (User 지시어 참고) 실행되기때문에, + 스크립트 엔진이 실행하는 스크립트는 잠재적으로 서버 사용자가 + 접근할 수 있는 모든 것에 접근할 수 있다. 어떤 스크립트 엔진은 + 어느정도 제한을 하지만, 안전하다고 가정하지 않는 것이 좋다.

+ +
top
+
+

시스템 설정 보호하기

+ + + +

정말로 안전한 서버를 운영하려면 사용자가 + .htaccess 파일을 사용하여 당신이 설정한 보안기능을 + 변경하길 바라지 않을 것이다. 그러기위해 다음과 같은 방법이 + 있다.

+ +

서버 설정파일에 다음을 추가한다

+ +

+ <Directory />
+ AllowOverride None
+ </Directory> +

+ +

그러면 사용가능하도록 명시적으로 허용한 디렉토리를 제외하고는 + .htaccess 파일을 사용할 수 없다.

+ +
top
+
+

기본적으로 서버에 있는 파일 보호하기

+ + + +

사람들은 종종 아파치의 기본 접근에 대해 잘못 알고있다. + 즉, 서버가 일반적인 URL 대응 규칙을 사용하여 파일을 찾을 + 수 있다면, 특별히 조치를 하지 않는한 클라이언트에게 파일이 + 서비스될 수 있다.

+ +

예를 들어, 아래와 같은 경우:

+ +

+ # cd /; ln -s / public_html
+ http://localhost/~root/ 에 접근한다 +

+ +

그러면 클라이언트는 전체 파일시스템을 돌아다닐 수 있다. + 이를 막기위해 서버설정에서 다음과 같은 조치를 한다:

+ +

+ <Directory />
+ Order Deny,Allow
+ Deny from all
+ </Directory> +

+ +

그러면 파일시스템 위치에 대해 기본 접근이 거부된다. + 원하는 영역에 접근할 수 있도록 다음과 같은 Directory 블록을 추가한다.

+ +

+ <Directory /usr/users/*/public_html>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </Directory> +

+ +

Location과 Directory 지시어를 같이 사용하는 + 경우 특별히 주의를 기울여라. 예를 들어, <Directory + />가 접근을 거부하더라도 <Location + /> 지시어가 이를 무시할 수 있다

+ +

UserDir 지시어를 + 사용하는 경우에도 주의하라. 지시어를 "./" 같이 설정하면 + root 사용자에 대해 바로 위의 경우와 같은 문제가 발생한다. + 아파치 1.3 이상을 사용한다면 서버 설정파일에 아래 줄을 추가하길 + 강력히 권한다:

+ +

+ UserDir disabled root +

+ +
top
+
+

로그 살펴보기

+ + + +

실제로 서버에서 무슨 일이 있어나고 있는지 알려면 로그파일을 살펴봐야 한다. 로그파일은 + 이미 일어난 일만을 보고하지만, 서버에 어떤 공격이 있었는지 + 알려주고 현재 필요한 만큼 안전한지 확인하게 해준다.

+ +

여러가지 예:

+ +

+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10 +

+ +

첫번째 예는 잘못된 + Source.JSP 요청으로 서버정보를 알아낼 수 있는 Tomcat의 + 취약점를 이용하려는 공격 횟수를 알려주고, 두번째 예는 + 접근이 거부된 최근 클라이언트 10개를 다음과 같이 보여준다:

+ +

+ [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd +

+ +

잘 알 듯이 로그파일은 이미 발생한 사건만을 보고한다. + 그래서 클라이언트가 .htpasswd 파일에 접근할 + 수 있었다면 접근 로그에 + 다음과 같은 기록이 남을 것이다:

+ +

+ foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" +

+ +

즉, 당신은 서버 설정파일에서 다음 부분을 주석처리했을 + 것이다:

+ +

+ <Files ~ "^\.ht">
+ Order allow,deny
+ Deny from all
+ <Files> +

+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/security_tips.xml.ko b/docs/manual/misc/security_tips.xml.ko index 53c9a3a9cd..9d312b5ec1 100644 --- a/docs/manual/misc/security_tips.xml.ko +++ b/docs/manual/misc/security_tips.xml.ko @@ -1,7 +1,7 @@ - + +mod_alias - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_alias

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:파일시스템의 다른 부분들을 문서 계층구조에 포함하고, + URL 리다이렉션을 제공한다
상태:Base
모듈명:alias_module
소스파일:mod_alias.c
+

요약

+ +

이 모듈이 제공하는 지시어들을 사용하여 서버가 요청을 + 받을때 URL을 수정하거나 조작할 수 있다. Alias와 ScriptAlias 지시어는 URL을 + 파일시스템 경로로 대응한다. 그래서 DocumentRoot 아래에 없는 내용을 + 웹으로 서비스할 수 있다. 또, ScriptAlias 지시어는 지정한 + 디렉토리에 CGI 스크립트밖에 없다고 알린다.

+ +

Redirect 지시어는 + 클라이언트에게 다른 URL로 새로운 요청을 하도록 지시한다. + 자원을 새로운 장소로 옮긴 경우 자주 사용한다.

+
+

지시어들

+ +

주제

+

참고

+
+
top
+
+

처리 순서

+ +

서로 다른 사용장소에서 Alias와 Redirect를 사용하면 다른 지시어와 +같이 표준 결합 방법에 +따라 처리한다. 그러나 같은 사용장소에 (예를 들어, 같은 <VirtualHost> 섹션에) +Alias와 Redirect를 사용하면 아래 순서대로 처리한다.

+ +

먼저 모든 Redirect를 처리한 후 Alias를 처리한다. 그래서 +Redirect나 RedirectMatch에 해당하는 요청은 +절대로 Alias하지 않는다. 그리고 Alias와 Redirect는 설정파일에서 +첫번째로 나오는 것을 사용한다.

+ +

그래서 여러 지시어가 동일한 하위경로에 해당하는 경우 모든 +지시어를 적용하기위해서는 가장 상세한 경로를 먼저 사용해야 한다. +예를 들어, 다음 설정은 의도한대로 동작한다:

+ +

+Alias /foo/bar /baz
+Alias /foo /gaq +

+ +

그러나 위의 두 지시어 순서를 바꾸면 /foo/bar +Alias 이전에 +/foo Alias를 +적용하므로 항상 두번째 지시어를 무시한다.

+ +
+
top
+

Alias 지시어

+ + + + + + +
설명:URL을 특정 파일시스템 장소로 대응한다
문법:Alias URL-path +file-path|directory-path
사용장소:주서버설정, 가상호스트
상태:Base
모듈:mod_alias
+ +

Alias 지시어를 사용하면 파일시스템에서 + DocumentRoot 밖에 있는 + 문서도 서비스할 수 있다. url-path로 시작하는 + (%로 인코딩된) URL을 directory-path로 시작하는 + 파일에 대응한다.

+ +

예제:

+ Alias /image /ftp/pub/image +

+ +

http://myserver/image/foo.gif를 요청하면 서버는 + /ftp/pub/image/foo.gif 파일을 넘겨준다.

+ +

url-path 끝에 /를 포함하면, URL 끝에 /를 + 사용해야만 영향이 있음을 주의하라. 즉, Alias /icons/ + /usr/local/apache/icons/ 설정은 url /icons와 + 관계가 없다.

+ +

대응의 대상을 포함하는 여러 <Directory> 섹션이 + 필요할지도 모른다. 이 지시어는 <Directory> 섹션을 검사하기 전에 + 처리하므로, 대응의 대상만 섹션의 영향을 받는다. (그러나 + <Location> + 섹션은 이 지시어를 처리하기 전에 한번만 검사하므로 지정한 + URL 이하 전체에 영향을 준다.)

+ +

특히 DocumentRoot + 밖에 있는 디렉토리로 Alias를 만들었다면, 직접 + 대상 디렉토리의 접근을 허용해줘야 한다.

+ +

예제:

+ Alias /image /ftp/pub/image
+ <Directory /ftp/pub/image>
+ + Order allow,deny
+ Allow from all
+ + </Directory> +

+ + +
+
top
+

AliasMatch 지시어

+ + + + + + +
설명:정규표현식을 사용하여 URL을 파일시스템 장소로 +대응한다
문법:AliasMatch regex +file-path|directory-path
사용장소:주서버설정, 가상호스트
상태:Base
모듈:mod_alias
+

이 지시어는 Alias와 + 같지만, 간단히 URL의 앞부분만 비교하는 대신 표준 정규표현식을 + 사용한다. 지정한 정규표현식을 URL 경로와 비교하여 맞다면, + 서버는 괄호로 묶은 부분을 대체하여 파일명으로 사용한다. + 예를 들어, 다음과 같이 /icons 디렉토리를 사용할 + 수 있다:

+ +

+ AliasMatch ^/icons(.*) /usr/local/apache/icons$1 +

+ +
+
top
+

Redirect 지시어

+ + + + + + + +
설명:클라이언트가 다른 URL에 접속하도록 요청하는 외부 +리다이렉션을 보낸다
문법:Redirect [status] URL-path +URL
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_alias
+

Redirect 지시어는 이전 URL을 새로운 URL로 대응한다. + 클라이언트에게 새로운 URL을 보내고, 클라이언트는 새로운 + 주소로 다시 한번 접속한다. (%로 인코딩된) URL-path로 + 시작하는 요청을 받으면 (%로 인코딩된) URL로 시작하는 + 새로운 URL로 리다이렉션 오류를 보낸다.

+ +

예제:

+ Redirect /service http://foo2.bar.com/service +

+ +

클라이언트가 http://myserver/service/foo.txt를 요청하면 + 대신 http://foo2.bar.com/service/foo.txt에 접근하라는 응답을 + 받는다.

+ +

주의

Redirect 지시어는 설정파일에서 +나오는 순서와 관계없이 Alias와 ScriptAlias 지시어보다 우선순위가 +높다. 또, .htaccess 파일이나 <Directory> 섹션에서 사용하더라도 +URL-path에는 상대경로가 아니라 반드시 완전한 URL을 +사용해야 한다.

+ +

status 아규먼트를 지정하지않으면, "임시 + (temporary)" (HTTP 상태 302) 리다이렉션을 보낸다. 즉, + 클라이언트에게 자원을 임시로 옮겼다고 알린다. status + 아규먼트를 사용하여 다른 HTTP 상태코드를 반환할 수 있다:

+ +
+
permanent
+ +
자원을 완전히 옮겼음을 뜻하는 영구 리다이렉션 상태를 + (301) 반환한다.
+ +
temp
+ +
임시 리다이렉션 상태를 (302) 반환한다. 기본값이다.
+ +
seeother
+ +
자원이 교체되었음을 뜻하는 "참조 (See Other)" 상태를 + (303) 반환한다.
+ +
gone
+ +
자원이 영구히 삭제되었음을 뜻하는 "소멸 (Gone)" 상태를 + (410) 반환한다. 이 상태를 사용하면 URL 아규먼트를 + 사용할 수 없다.
+
+ +

status에 숫자 상태코드를 사용하여 다른 상태코드도 + 반환할 수 있다. 상태가 300과 399 사이라면 URL + 아규먼트를 사용해야 하고, 아니라면 생략해야 한다. 단, 아파치 + 코드에 상태가 정의되있어야 한다 (http_protocol.c의 + send_error_response 함수 참고).

+ +

예제:

+ Redirect permanent /one http://example.com/two
+ Redirect 303 /three http://example.com/other +

+ + +
+
top
+

RedirectMatch 지시어

+ + + + + + + +
설명:현재 URL이 정규표현식에 해당하면 외부 리다이렉션을 +보낸다
문법:RedirectMatch [status] regex +URL
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_alias
+

이 지시어는 Redirect와 같지만, 간단히 + URL의 앞부분만 비교하는 대신 표준 정규표현식을 사용한다. + 지정한 정규표현식을 URL 경로와 비교하여 맞다면, 서버는 괄호로 + 묶은 부분을 대체하여 파일명으로 사용한다. 예를 들어, 다음은 + 모든 GIF 파일 요청에 대해 다른 서버의 비슷한 이름을 가진 + JPEG 파일로 리다이렉션을 보낸다:

+ +

+ RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg +

+ +
+
top
+

RedirectPermanent 지시어

+ + + + + + + +
설명:클라이언트가 다른 URL에 접속하도록 요청하는 외부 +영구 리다이렉션을 보낸다
문법:RedirectPermanent URL-path URL
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_alias
+

이 지시어는 클라이언트에게 리다이렉션이 영구적임을 (상태 + 301) 알린다. Redirect permanent와 정확히 같다.

+ +
+
top
+

RedirectTemp 지시어

+ + + + + + + +
설명:클라이언트가 다른 URL에 접속하도록 요청하는 외부 +임시 리다이렉션을 보낸다
문법:RedirectTemp URL-path URL
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_alias
+

이 지시어는 클라이언트에게 리다이렉션이 임시적임을 (상태 + 302) 알린다. Redirect temp와 정확히 같다.

+ +
+
top
+

ScriptAlias 지시어

+ + + + + + +
설명:URL을 특정 파일시스템 장소로 대응하고 대상이 CGI +스크립트라고 알린다
문법:ScriptAlias URL-path +file-path|directory-path
사용장소:주서버설정, 가상호스트
상태:Base
모듈:mod_alias
+

ScriptAlias 지시어는 Alias 지시어와 비슷하지만, + 추가로 대상 디렉토리에 mod_cgi의 cgi-script + 핸들러가 처리할 CGI 스크립트가 있다고 알린다. + URL-path로 시작하는 (%로 인코딩된) URL을 파일시스템의 + 절대경로인 두번째 아규먼트로 시작하는 스크립트에 대응한다.

+ +

예제:

+ ScriptAlias /cgi-bin/ /web/cgi-bin/ +

+ +

http://myserver/cgi-bin/foo를 요청하면 서버는 + /web/cgi-bin/foo 스크립트를 실행한다.

+ +
+
top
+

ScriptAliasMatch 지시어

+ + + + + + +
설명:정규표현식을 사용하여 URL을 특정 파일시스템 장소로 +대응하고 대상이 CGI 스크립트라고 알린다
문법:ScriptAliasMatch regex +file-path|directory-path
사용장소:주서버설정, 가상호스트
상태:Base
모듈:mod_alias
+

이 지시어는 ScriptAlias와 같지만, 간단히 + URL의 앞부분만 비교하는 대신 표준 정규표현식을 사용한다. + 지정한 정규표현식을 URL 경로와 비교하여 맞다면, 서버는 괄호로 + 묶은 부분을 대체하여 파일명으로 사용한다. 예를 들어, 다음과 + 같이 표준적인 /cgi-bin을 사용할 수 있다:

+ +

+ ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1 +

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_alias.xml.ko b/docs/manual/mod/mod_alias.xml.ko index a44a221937..c4d466d361 100644 --- a/docs/manual/mod/mod_alias.xml.ko +++ b/docs/manual/mod/mod_alias.xml.ko @@ -1,7 +1,7 @@ - + +mod_auth_basic - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_auth_basic

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:Basic authentication
상태:Base
모듈명:auth_basic_module
소스파일:mod_auth_basic.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 해당 제공자(provider)를 사용하여 사용자별로 + 접근을 제한하는 HTTP Basic Authentication을 제공한다. + HTTP Digest Authentication은 mod_auth_digest가 + 제공한다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthBasicAuthoritative 지시어

+ + + + + + + + +
설명:인증과 권한부여를 저수준 모듈에 넘겨줄지 결정한다
문법:AuthBasicAuthoritative On|Off
기본값:AuthBasicAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_auth_basic
+

AuthBasicAuthoritative 지시어를 + Off로 설정하면 주어진 사용자 아이디에 해당하는 + 사용자 아이디나 규칙을 + 찾을 수 없는 경우 인증과 권한부여 모두를 (modules.c + 파일에서 정의한) 저수준 모듈로 넘겨준다. 주어진 사용자 + 아이디나 규칙을 찾았다면 보통때와 같이 암호와 접근허용여부를 + 검사하고, 실패하면 "Authentication Required (인증 필요)" + 응답을 한다.

+ +

그래서 여러 모듈의 데이터베이스에 사용자 아이디가 있거나 + 유효한 Require 지시어를 + 여러 모듈에 적용하면, 첫번째 모듈이 사용자를 검사하고, + AuthBasicAuthoritative 설정과 관계없이 + 접근을 넘기지않는다.

+ +

기본적으로 제어를 넘기지않고, 모르는 사용자 아이디와 + 규칙인 경우 "Authentication Required (인증 필요)" 응답을 + 한다. 이 지시어를 설정하지않으면 시스템이 안전하게 유지되며, + NCSA 웹서버와 같이 동작한다.

+ +
+
top
+

AuthBasicProvider 지시어

+ + + + + + + + +
설명:이 위치에 대한 인증제공자를 지정한다
문법:AuthBasicProvider On|Off|provider-name +[provider-name] ...
기본값:AuthBasicProvider On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_auth_basic
+

AuthBasicProvider 지시어는 이 + 위치에서 사용자를 인증할 제공자를 지정한다. 값이 + On이면 기본제공자(file)를 선택한다. + mod_authn_file 모듈이 file + 제공자를 구현하기때문에 서버에 이 모듈이 있는지 확인해야 + 한다.

+ +

예제

+ <Location /secure>
+ + AuthBasicProvider dbm
+ AuthDBMType SDBM
+ AuthDBMUserFile /www/etc/dbmpasswd
+ Require valid-user
+ + </Location> +

+ +

제공자는 mod_authn_dbm과 + mod_authn_file을 참고하라.

+ +

값이 Off이면 제공자 목록을 지우고 기본상태로 + 돌아간다.

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_auth_basic.xml.ko b/docs/manual/mod/mod_auth_basic.xml.ko index c34be7bc82..6ec4fb832f 100644 --- a/docs/manual/mod/mod_auth_basic.xml.ko +++ b/docs/manual/mod/mod_auth_basic.xml.ko @@ -1,7 +1,7 @@ - + +mod_auth_digest - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_auth_digest

+
+

가능한 언어:  en  | + ko 

+
+ + + +
설명:MD5 Digest Authentication을 사용한 사용자인증.
상태:Experimental
모듈명:auth_digest_module
소스파일:mod_auth_digest.c
+

요약

+ +

이 모듈은 HTTP Digest Authentication을 구현한다. + 그러나 많은 테스트를 거치지 않은 실험적인 모듈이다.

+
+

지시어들

+ +

주제

+

참고

+
+
top
+
+

Digest Authentication 사용하기

+ +

MD5 Digest authentication은 매우 쉽게 사용할 수 있다. + AuthType Basic과 AuthBasicProvider 대신 + AuthType Digest와 AuthDigestProvider를 + 사용하여 간단히 인증을 설정할 수 있다. 그리고 최소한 보호하려는 + 영역의 기본 URI을 AuthDigestDomain 지시어에 사용한다.

+ +

htdigest 도구를 + 사용하여 사용자 (문자)파일을 만들 수 있다.

+ +

예제:

+ <Location /private/>
+ + AuthType Digest
+ AuthName "private area"
+ AuthDigestDomain /private/ http://mirror.my.dom/private2/
+
+ AuthDigestProvider file
+ AuthUserFile /web/auth/.digest_pw
+ Require valid-user
+ + </Location> +

+ +

주의

+

Digest authentication은 Basic authentication보다 더 + 안전한 암호시스템을 제공하지만, 브라우저가 지원해야 한다. + 2002년 11월 현재 digest authentication을 지원하는 브라우저에는 + Opera, (질의문자열과 + 함께 사용할 수 없지만) MS Internet + Explorer, Amaya, Mozilla, 버전 7 이후의 + Netscape 등이 있다. digest authentication이 basic + authentication 만큼 널리 구현되지 않았기때문에 주의해서 + 사용해야 한다.

+
+
+
top
+

AuthDigestAlgorithm 지시어

+ + + + + + + + +
설명:digest authentication에서 challenge와 response +hash를 계산하는 알고리즘을 선택한다
문법:AuthDigestAlgorithm MD5|MD5-sess
기본값:AuthDigestAlgorithm MD5
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestAlgorithm 지시어는 + challenge와 response hash를 계산하는 알고리즘을 선택한다.

+ +
+ MD5-sess는 아직 완전히 구현되지 않았다. +
+ + +
+
top
+

AuthDigestDomain 지시어

+ + + + + + + +
설명:digest authentication에서 같은 보호영역에 속하는 +URI들
문법:AuthDigestDomain URI [URI] ...
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestDomain 지시어는 같은 + 보호영역에 있는 (예를 들어 같은 영역과 사용자명/암호 + 정보를 사용하는) URI들을 지정한다. 지정한 URI는 접두사로 + 사용한다. 클라이언트는 URI "아래" 모두를 + 같은 사용자명/암호로 보호한다고 가정한다. URI는 + (즉, 스킴(scheme), 호스트, 포트 등을 포함하는) + 절대 URL이거나 상대 URI이다.

+ +

이 지시어는 항상 지정해야 하며, 최소한 영역들의 + 기본 URI(들)를 포함해야 한다. 생략하면 클라이언트는 + 이 서버로 보내는 모든 요청에 Authorization 헤더를 + 포함한다. 그러면 요청의 크기가 커지며, AuthDigestNcCheck를 + 사용한다면 성능에 나쁜 영향을 줄 수 있다.

+ +

다른 서버의 URI를 지정하면, (이를 이해하는) 클라이언트는 + 여러 서버마다 매번 사용자에게 묻지않고 같은 사용자명/암호를 + 사용할 수 있다.

+ +
+
top
+

AuthDigestNcCheck 지시어

+ + + + + + + +
설명:서버가 보내는 nonce-count를 검사할지 여부
문법:AuthDigestNcCheck On|Off
기본값:AuthDigestNcCheck Off
사용장소:주서버설정
상태:Experimental
모듈:mod_auth_digest
+
+ 아직 구현되지 않았다. +
+ + +
+
top
+

AuthDigestNonceFormat 지시어

+ + + + + + + +
설명:nonce를 만드는 방법을 결정한다
문법:AuthDigestNonceFormat format
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+
아직 구현되지 않았다.
+ + +
+
top
+

AuthDigestNonceLifetime 지시어

+ + + + + + + + +
설명:서버 nonce가 유효한 기간
문법:AuthDigestNonceLifetime seconds
기본값:AuthDigestNonceLifetime 300
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestNonceLifetime 지시어는 + 서버 nonce가 유효한 기간을 조절한다. 클라이언트가 만기된 + nonce를 가지고 서버에 접근하면 서버는 stale=true와 + 함께 401을 반환한다. seconds가 0보다 크면 nonce가 + 유효한 기간을 지정한다. 아마도 10 초보다 작게 설정하면 안된다. + seconds가 0보다 작으면 nonce는 영원히 만기되지 + 않는다. +

+ +
+
top
+

AuthDigestProvider 지시어

+ + + + + + + + +
설명:이 위치에 대한 인증제공자를 지정한다
문법:AuthDigestProvider On|Off|provider-name +[provider-name] ...
기본값:AuthDigestProvider On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestProvider 지시어는 이 + 위치에서 사용자를 인증할 제공자를 지정한다. 값이 + On이면 기본제공자(file)를 사용한다. + mod_authn_file 모듈이 file + 제공자를 구현하기때문에 서버에 이 모듈이 있는지 확인해야 + 한다.

+ +

제공자는 mod_authn_dbm과 + mod_authn_file을 참고하라.

+ +

값이 Off이면 제공자 목록을 지우고 기본상태로 + 돌아간다.

+ +
+
top
+

AuthDigestQop 지시어

+ + + + + + + + +
설명:digest authentication가 사용할 +보호수준(quality-of-protection)을 지정한다.
문법:AuthDigestQop none|auth|auth-int [auth|auth-int]
기본값:AuthDigestQop auth
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestQop 지시어는 + 보호수준(quality-of-protection)을 지정한다. + auth는 (사용자명/암호) 인증만 하고, + auth-int는 인증과 완결성 검사를 (MD5 해쉬도 + 계산하여 검사한다) 한다. none은 (완결성 검사를 + 하지않는) 오래된 RFC-2069 digest 알고리즘을 사용한다. + auth와 auth-int를 모두 지정할 + 수 있다. 이 경우 브라우저는 어떤 것을 사용할지 선택한다. + 브라우저가 어던 이유에서건 challenge를 좋아하지 않는다면 + none을 사용해야 한다.

+ +
+ auth-int는 아직 구현되지 않았다. +
+ +
+
top
+

AuthDigestShmemSize 지시어

+ + + + + + + +
설명:클라이언트를 추적하기위해 할당하는 공유메모리량
문법:AuthDigestShmemSize size
기본값:AuthDigestShmemSize 1000
사용장소:주서버설정
상태:Experimental
모듈:mod_auth_digest
+

AuthDigestShmemSize 지시어는 + 클라이언트를 추적하기위해 서버가 시작할때 할당하는 + 공유메모리량을 정의한다. 공유메모리는 최소한 하나의 + 클라이언트를 추적하기위해 필요한 공간보다 작을 수 없음을 + 주의하라. 이 값은 시스템에 따라 다르다. 정확한 값을 알려면 + AuthDigestShmemSize를 0으로 + 설정하고 서버를 시작한후 오류문을 참고하라.

+ +

size는 보통 바이트 단위이지만, 뒤에 + K나 M을 사용하여 KBytes나 MBytes를 + 나타낼 수 있다. 예를 들어, 다음 지시어들은 모두 같다:

+ +

+ AuthDigestShmemSize 1048576
+ AuthDigestShmemSize 1024K
+ AuthDigestShmemSize 1M +

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_auth_digest.xml.ko b/docs/manual/mod/mod_auth_digest.xml.ko index 6f0dfa4637..75924f3b58 100644 --- a/docs/manual/mod/mod_auth_digest.xml.ko +++ b/docs/manual/mod/mod_auth_digest.xml.ko @@ -1,7 +1,7 @@ - + +mod_authn_anon - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authn_anon

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:인증영역에 "익명(anonymous)" 사용자의 접근을 +허용한다
상태:Extension
모듈명:authn_anon_module
소스파일:mod_authn_anon.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 mod_auth_basic 등 인증앞단모듈을 + 위해 (예를 들어 '특별한' 사용자 아이디 'anonymous'와 + 전자우편 주소를 암호로 사용하는) 익명-ftp 사이트와 유사한 + 사용자 인증을 한다. 전자우편 주소를 로그에 기록할 수 있다.

+ +

다른 (데이터베이스) 접근제어 방식과 함께 사용하여 + '등록하지않은' 사용자에게 사이트를 열어두면서 효율적인 사용자 + 추적과 사용자정의가 가능하다. 인증기반 사용자 추적은 쿠키나 + 괴상한 URL 접두사/접미사와 달리 완전히 브라우저 독립적이고 + 사용자가 URL을 공유할 수 있다는 장점이 있다.

+ +

mod_auth_basic을 사용할때 AuthBasicProvider의 + 값으로 anon을 설정하면 이 모듈을 사용한다.

+
+

지시어들

+ +

주제

+
+
top
+
+

예제

+

다음 예는 "일반적인" htpasswd-파일기반 인증에 추가로 + 사용자가 다음 조건을 만족한다면 '손님(guest)'으로 접근할 + 수 있도록 한다:

+ + + +

예제

+ <Directory /foo> + + AuthName "손님으로 방문하려면 'anonymous'와 전자우편 주소를 사용하라"
+ AuthType Basic
+ AuthBasicProvider file anon
+ AuthUserFile /path/to/your/.htpasswd
+
+ Anonymous_NoUserID off
+ Anonymous_MustGiveEmail on
+ Anonymous_VerifyEmail on
+ Anonymous_LogEmail on
+ Anonymous anonymous guest www test welcome
+
+ Order Deny,Allow
+ Allow from all
+
+ Require valid-user
+ + </Directory> +

+
+
top
+

Anonymous 지시어

+ + + + + + + +
설명:암호검사없이 접근을 허용할 사용자 아이디들을 +지정한다
문법:Anonymous user [user] ...
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_anon
+

암호검사없이 접근을 허용할 '특별한' 사용자 아이디 목록. + 사용자 아이디들을 공백으로 구분한다. 따옴표 '와 "나 탈출문자 + \를 사용하여 사용자 아이디 안에 공백을 포함할 수 있다.

+ +

아이디는 대소문자를 구별하지않음을 + 주의하라.
+ 허용할 사용자 아이디에 특별한 사용자명인 + 'anonymous'를 항상 포함하길 강력히 권한다.

+ +

예제:

+ Anonymous anonymous "Not Registered" "I don't know" +

+ +

"anonymous", "AnonyMous", "Not Registered", "I Don't Know" + 등 사용자 아이디를 사용하면 암호검사없이 사용자를 허용한다.

+ +

아파치 2.1에서는 사용자 아이디로 "*"를 + 사용할 수 있다. 그러면 어떤 사용자 아이디라도 + 받아들인다.

+ +
+
top
+

Anonymous_LogEmail 지시어

+ + + + + + + + +
설명:입력한 암호를 오류로그에 기록할지 여부
문법:Anonymous_LogEmail On|Off
기본값:Anonymous_LogEmail On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_anon
+

기본값인 On으로 설정하면 (아마도 전자우편 + 주소일) 입력한 '암호'를 오류로그에 기록한다.

+ +
+
top
+

Anonymous_MustGiveEmail 지시어

+ + + + + + + + +
설명:암호가 없어도 가능한지 여부
문법:Anonymous_MustGiveEmail On|Off
기본값:Anonymous_MustGiveEmail On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_anon
+

사용자가 암호로 전자우편 주소를 입력해야 하는지 여부를 + 결정한다. 암호가 없으면 거부한다.

+ +
+
top
+

Anonymous_NoUserID 지시어

+ + + + + + + + +
설명:사용자 아이디가 없어도 가능하지 여부
문법:Anonymous_NoUserID On|Off
기본값:Anonymous_NoUserID Off
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_anon
+

On으로 설정하면 사용자는 사용자 아이디를 + (아마 암호도) 입력하지 않아도 된다. 이는 자연스럽게 그냥 + return을 치거나 OK 버튼을 클릭하는 MS-Explorer 사용자에게 + 매우 편리하다.

+ +
+
top
+

Anonymous_VerifyEmail 지시어

+ + + + + + + + +
설명:암호가 올바른 형식의 전자우편 주소인지 검사 +여부
문법:Anonymous_VerifyEmail On|Off
기본값:Anonymous_VerifyEmail Off
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_anon
+

On으로 설정하면 사용자가 올바른 전자우편 + 주소를 입력하도록 입력한 '암호'가 최소한 '@'와 '.'를 한개씩 + 포함하는지 검사한다 (위의 Anonymous_LogEmail 참고).

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authn_anon.xml.ko b/docs/manual/mod/mod_authn_anon.xml.ko index 2123fe82ec..1c4e2c1f48 100644 --- a/docs/manual/mod/mod_authn_anon.xml.ko +++ b/docs/manual/mod/mod_authn_anon.xml.ko @@ -1,7 +1,7 @@ - + +mod_authn_dbm - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authn_dbm

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:DBM 파일을 사용한 사용자 인증
상태:Extension
모듈명:authn_dbm_module
소스파일:mod_authn_dbm.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 mod_auth_digest나 + mod_auth_basic 인증앞단모듈을 위해 + dbm 암호파일에서 사용자를 찾아서 인증한다. + mod_authn_file과 기능이 비슷한다.

+ +

mod_auth_basic이나 + mod_auth_digest를 사용할때 AuthBasicProvider나 + AuthDigestProvider의 + 값으로 dbm을 설정하면 이 모듈을 사용한다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthDBMType 지시어

+ + + + + + + + +
설명:암호를 저장하는 데이터베이스 파일 종류를 +지정한다
문법:AuthDBMType default|SDBM|GDBM|NDBM|DB
기본값:AuthDBMType default
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_dbm
+

암호를 저장하는 데이터베이스 파일 종류를 지정한다. 기본 + 데이터베이스 종류는 컴파일때 판단한다. 사용할 수 있는 다른 + 데이터베이스 파일 종류도 컴파일 + 설정에 달렸다.

+ +

암호파일을 만드는 프로그램이 같은 종류의 데이터베이스를 + 사용하도록 설정해야 한다.

+ +
+
top
+

AuthDBMUserFile 지시어

+ + + + + + + +
설명:인증할 사용자와 암호 목록을 저장하는 데이터베이스 +파일명을 지정한다
문법:AuthDBMUserFile file-path
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authn_dbm
+

AuthDBMUserFile 지시어는 사용자 + 인증에 사용할 사용자와 암호 목록을 저장하는 DBM 파일명을 + 지정한다. File-path는 파일의 절대경로이다.

+ +

파일은 사용자명을 키로 사용한다. 사용자에 대한 값은 + 인코딩된 암호이다. 암호 뒤에 콜론과 임의의 정보가 나올 수 + 있다. 서버는 콜론과 뒤에 나오는 정보를 무시한다.

+ +

보안:

+

AuthDBMUserFile이 웹서버의 문서들 + 밖에 있음을 확인하라. 이 파일을 보호할 디렉토리 안에 같이 + 두지 마라. 그렇지 않으면, 클라이언트가 + AuthDBMUserFile을 다운로드할 수 + 있다.

+
+ +

중요한 호환성 주의: 아파치 모듈의 dbmopen + 구현은 문자열 끝의 NULL에 의존하지않고 DBM 자료구조에서 + 해싱값의 문자열 길이를 읽는다. Netscape 웹서버 등 어떤 + 프로그램은 문자열이 NULL로 끝난다고 가정하기때문에 여러 + 프로그램이 DBM 파일을 사용하면 문제가 될 수 있다.

+ +

아파치는 dbmmanage라는 + Perl 스크립트를 포함한다. 이 프로그램은 이 모듈이 사용할 + DBM형식 암호파일을 만들고 수정한다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authn_dbm.xml.ko b/docs/manual/mod/mod_authn_dbm.xml.ko index 8960795a91..d5b699f24b 100644 --- a/docs/manual/mod/mod_authn_dbm.xml.ko +++ b/docs/manual/mod/mod_authn_dbm.xml.ko @@ -1,7 +1,7 @@ - + +mod_authn_default - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authn_default

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:최후 인증모듈
상태:Base
모듈명:authn_default_module
소스파일:mod_authn_default.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 mod_auth_basic과 같은 인증모듈을 + 설정하지않은 최후의 경우 대신 사용한다. 이 모듈은 사용자가 + 제공한 어떠한 정보도 거부한다.

+
+

지시어들

+ +
+ +
top
+

AuthDefaultAuthoritative 지시어

+ + + + + + + + +
설명:인증을 저수준 모듈로 넘겨줄지 여부
문법:AuthDefaultAuthoritative On|Off
기본값:AuthDefaultAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authn_default
+

AuthDefaultAuthoritative 지시어를 + 직접 Off로 설정하면 (modules.c + 파일에서 정의한) 저수준 모듈로 인증을 넘겨준다.

+ +

주의

+

mod_authn_default가 이미 매우 + 저수준으로 정의되있기 때문에 보통 더 낮은 모듈이 없다. + 그러므로 AuthDefaultAuthoritative를 + 기본값(On)으로 남겨둬야 한다.

+
+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authn_default.xml.ko b/docs/manual/mod/mod_authn_default.xml.ko index aacb430181..e4c51d1935 100644 --- a/docs/manual/mod/mod_authn_default.xml.ko +++ b/docs/manual/mod/mod_authn_default.xml.ko @@ -1,7 +1,7 @@ - + +mod_authn_file - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authn_file

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:문자파일을 이용한 사용자 인증
상태:Base
모듈명:authn_file_module
소스파일:mod_authn_file.c
지원:아파치 2.1 이후
+

요약

+ +

이 모듈은 mod_auth_digest와 + mod_auth_basic 같은 인증앞단모듈을 위해 + 일반 문자 암호파일에서 사용자를 찾아서 인증한다. + mod_authn_dbm과 기능이 비슷하다.

+ +

mod_auth_basic이나 + mod_auth_digest를 사용할때 AuthBasicProvider나 + AuthDigestProvider의 + 값을 file로 설정하면 이 모듈을 사용한다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthUserFile 지시어

+ + + + + + + +
설명:인증할 사용자명와 암호 목록을 저장하는 문자파일명을 +지정한다
문법:AuthUserFile file-path
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authn_file
+

AuthUserFile 지시어는 사용자 인증에 + 사용할 사용자명와 암호 목록을 저장하는 문자파일명을 지정한다. + File-path는 파일경로이다. 절대경로를 사용하지 + 않으면 ServerRoot의 + 상대경로로 처리한다.

+ +

파일의 각 줄에는 사용자명, 콜론, 인코딩된 암호가 순서대로 + 나온다. 여러 줄에서 동일한 사용자 아이디를 정의하면, + mod_authn_file는 첫번째로 나오는 암호를 + 사용한다.

+ +

컴파일된 배포본이나 src/support에 있는 htpasswd 도구는 HTTP + Basic Authentication에 사용할 암호파일을 관리한다. + 자세한 내용은 manpage를 + 참고하라. 요약하면:

+ +

초기 아이디 username을 가진 암호파일 + Filename을 만든다. 암호를 물어본다:

+ +

+ htpasswd -c Filename username +

+ +

암호파일 Filename에 username2를 + 추가하거나 수정한다:

+ +

+ htpasswd Filename username2 +

+ +

큰 문자파일을 검색하는 것은 매우 비효율적임을 + 주의하라. 사용자가 많다면 대신 AuthDBMUserFile을 사용해야 + 한다.

+ +

HTTP Digest Authentication을 사용한다면 htpasswd 도구로 안된다. + 대신 htdigest를 + 사용해야 한다. Digest Authentication과 Basic Authentication을 + 위한 자료를 같은 파일에 섞어서 사용할 수 없음을 주의하라.

+ +

보안

+

AuthUserFile이 웹서버의 문서들 + 밖에 위치함을 확인하라. 이 파일을 보호할 디렉토리 안에 + 같이 두지 마라. 그렇지 않으면, 클라이언트가 + AuthUserFile을 다운로드할 수 있다.

+
+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authn_file.xml.ko b/docs/manual/mod/mod_authn_file.xml.ko index b85fdaedd3..3dd32dbedf 100644 --- a/docs/manual/mod/mod_authn_file.xml.ko +++ b/docs/manual/mod/mod_authn_file.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_dbm - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_dbm

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:DBM 파일을 사용한 그룹 인증
상태:Extension
모듈명:authz_dbm_module
소스파일:mod_authz_dbm.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 인증한 사용자의 그룹권한으로 웹의 일부를 접근할 + 수 있는지 결정하여 권한부여를 한다. + mod_authz_groupfile과 기능이 비슷하다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthDBMGroupFile 지시어

+ + + + + + + +
설명:인증에 사용할 사용자 그룹 목록을 저장하는 데이터베이스 +파일명을 지정한다
문법:AuthDBMGroupFile file-path
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authz_dbm
+

AuthDBMGroupFile 지시어는 인증에 + 사용할 사용자 그룹 목록을 저장하는 DBM 파일명을 지정한다. + File-path는 파일의 절대경로이다.

+ +

파일은 사용자명을 키로 사용한다. 사용자에 대한 값은 쉼표로 + 구분한 사용자가 속한 그룹 목록이다. 값에 공백이나 콜론을 + 사용할 수 없다.

+ +

보안

+

AuthDBMGroupFile이 웹서버의 + 문서들 밖에 위치함을 확인하라. 이 파일을 보호할 디렉토리 + 안에 같이 두지 마라. 그렇지 않으면, 클라이언트가 + AuthDBMGroupFile를 다운로드할 수 + 있다.

+
+ +

그룹 DBM 파일과 암호 DBM 파일을 같이 사용하기: 사용자에 + 대한 암호와 그룹 정보 모두를 한 데이터베이스에서 관리하는 + 것이 쉬울때가 있다. 이 경우 작성할 지원 프로그램이 간단해진다. + 프로그램은 한 DBM 파일만을 잠그고 쓰면 된다. 그룹파일과 + 암호파일을 같은 DBM파일로 설정하면 가능하다:

+ +

+ AuthDBMGroupFile /www/userbase
+ AuthDBMUserFile /www/userbase +

+ +

이 통합 DBM의 키는 사용자명이다. 값은 다음과 같다

+ +

+ 인코딩된 암호 : 그룹 목록 [ : (무시) ] +

+ +

암호 부분은 전과 같이 인코딩된 암호이다. 콜론 뒤에 쉼표로 + 구분한 그룹 목록이 나온다. 또 다시 콜론 다음에 다른 정보를 + 기록할 수 있다. 이 부분은 인증모듈이 무시한다. + www.telescope.org는 이렇게 암호 데이터베이스와 그룹 + 데이터베이스를 같이 사용한다.

+ +
+
top
+

AuthzDBMAuthoritative 지시어

+ + + + + + + + +
설명:권한부여를 저수준 모듈로 넘겨줄지 여부
문법:AuthzDBMAuthoritative On|Off
기본값:AuthzDBMAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authz_dbm
+

AuthzDBMAuthoritative 지시어를 + 직접 Off로 설정하면 해당 사용자 아이디에 대한 + 그룹이 없는 경우 그룹 권한부여를 (modules.c + 파일에서 정의한) 저수준 모듈로 넘겨준다. 지정한 그룹이 있다면 + 보통때와 같이 검사하고, 실패하면 인증 필요 응답을 한다.

+ +

그래서 여러 모듈의 데이터베이스에 사용자 아이디가 있거나 + 유효한 Require 지시어를 + 여러 모듈에 적용하면, 첫번째 모듈이 사용자를 검사하고, + AuthAuthoritative 설정과 관계없이 + 접근을 넘기지않는다.

+ +

일반적으로 mod_authn_dbm이나 + mod_authn_file과 같은 인증제공자와 같이 + 사용한다. 대량의 사용자 검사에 대한 검사는 DBM 모듈을 + 사용하지만, 소수(관리자)에 대한 검사는 잘 보호된 + .htpasswd 파일로 넘긴다.

+ +

기본적으로 제어를 넘기지않고, 모르는 그룹의 경우 인증 + 필요 응답을 한다. 이 지시어를 설정하지않으면 시스템이 안전하게 + 유지되며, NCSA 웹서버와 같이 동작한다.

+ +

보안

+

사용자가 자신의 .htaccess 파일을 사용하게 되는지 살펴보고, + 이런 행동을 허용할지 결정하라. 일반적으로 여러가지 방법으로 + 접근할 수 있는 데이터베이스를 보호하는 것보다 하나의 + .htpasswd 파일을 보호하는 것이 더 쉽다.

+
+ +
+
top
+

AuthzDBMType 지시어

+ + + + + + + + +
설명:암호를 저장하는 데이터베이스 파일 종류를 지정한다
문법:AuthzDBMType default|SDBM|GDBM|NDBM|DB
기본값:AuthzDBMType default
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authz_dbm
+

암호를 저장하는 데이터베이스 파일 종류를 지정한다. + 데이터베이스 종류 기본값은 컴파일때 정해진다. 사용할 수 + 있는 다른 데이터베이스 파일 종류도 컴파일 설정에 달렸다.

+ +

암호파일을 만든 프로그램이 같은 종류의 데이터베이스를 + 사용하도록 설정해야 한다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_dbm.xml.ko b/docs/manual/mod/mod_authz_dbm.xml.ko index 5b19a9b5df..e644bc3ffa 100644 --- a/docs/manual/mod/mod_authz_dbm.xml.ko +++ b/docs/manual/mod/mod_authz_dbm.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_default - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_default

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:최후 권한부여모듈
상태:Base
모듈명:authz_default_module
소스파일:mod_authz_default.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 mod_authz_user나 + mod_authz_groupfile와 같은 권한부여모듈을 + 설정하지않은 최후의 경우 대신 사용한다. 이 모듈은 모든 권한부여 + 요청을 거부한다.

+
+

지시어들

+ +
+ +
top
+

AuthzDefaultAuthoritative 지시어

+ + + + + + + + +
설명:권한부여를 저수준 모듈로 넘겨줄지 여부
문법:AuthzDefaultAuthoritative On|Off
기본값:AuthzDefaultAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authz_default
+

AuthzDefaultAuthoritative 지시어를 + 직접 Off로 설정하면 (modules.c + 파일에서 정의한) 저수준 모듈로 권한부여를 넘겨준다.

+ +

주의

+

mod_authz_default가 이미 매우 + 저수준으로 정의되있기 때문에 보통 더 낮은 모듈이 + 없다. 그러므로 + AuthzDefaultAuthoritative를 + 기본값(On)으로 남겨둬야 한다.

+
+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_default.xml.ko b/docs/manual/mod/mod_authz_default.xml.ko index a0cd38adba..4d86685655 100644 --- a/docs/manual/mod/mod_authz_default.xml.ko +++ b/docs/manual/mod/mod_authz_default.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_groupfile - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_groupfile

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:일반 문자파일을 이용한 그룹 권한부여
상태:Base
모듈명:authz_groupfile_module
소스파일:mod_authz_groupfile.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 인증한 사용자의 그룹권한으로 웹사이트의 일부를 + 접근할 수 있는지 결정하여 권한부여를 한다. + mod_authz_dbm과 기능이 비슷하다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthGroupFile 지시어

+ + + + + + + +
설명:인증에 사용할 사용자 그룹 목록을 저장하는 문자파일명을 +지정한다
문법:AuthGroupFile file-path
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authz_groupfile
+

AuthGroupFile 지시어는 사용자 + 인증에 사용할 사용자 그룹 목록을 저장하는 문자파일명을 + 지정한다. File-path는 그룹파일 경로이다. 절대경로를 + 사용하지 않으면 ServerRoot의 상대경로로 받아들인다.

+ +

그룹파일의 각 줄에는 그룹명, 콜론, 공백으로 구분한 + 사용자명들이 순서대로 나온다.

+ +

예제:

+ mygroup: bob joe anne +

+ +

많은 그룹을 저장한 큰 문자파일을 검색하는 것은 매우 + 비효율적임을 주의하라. AuthDBMGroupFile이 더 성능이 좋다.

+ +

보안

+

AuthGroupFile이 웹서버의 문서들 + 밖에 위치함을 확인하라. 이 파일을 보호할 디렉토리 안에 + 같이 두지 마라. 그렇지 않으면, 클라이언트가 + AuthGroupFile을 다운로드할 수 있다.

+
+ +
+
top
+

AuthzGroupFileAuthoritative 지시어

+ + + + + + + + +
설명:권한부여를 저수준 모듈로 넘겨줄지 여부
문법:AuthzGroupFileAuthoritative On|Off
기본값:AuthzGroupFileAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authz_groupfile
+

AuthzGroupFileAuthoritative 지시어를 + 직접 Off로 설정하면 해당 사용자 아이디에 대한 + 그룹이 없는 경우 그룹 권한부여를 + (modules.c 파일에서 정의한) 저수준 모듈로 + 넘겨준다.

+ +

기본적으로 제어를 넘기지않고, 모르는 그룹의 경우 인증 + 필요 응답을 한다. 이 지시어를 설정하지않으면 시스템이 안전하게 + 유지되며, NCSA 웹서버와 같이 동작한다.

+ +

보안

+

사용자가 자신의 .htaccess 파일을 사용하게 되는지 살펴보고, + 이런 행동을 허용할지 결정하라. 일반적으로 여러가지 방법으로 + 접근할 수 있는 데이터베이스를 보호하는 것보다 하나의 + .htpasswd 파일을 보호하는 것이 더 쉽다.

+
+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_groupfile.xml.ko b/docs/manual/mod/mod_authz_groupfile.xml.ko index 6b7774ff49..ca5ea59a21 100644 --- a/docs/manual/mod/mod_authz_groupfile.xml.ko +++ b/docs/manual/mod/mod_authz_groupfile.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_host - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_host

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:호스트 (이름이나 IP 주소)를 사용한 그룹 권한부여
상태:Base
모듈명:authz_host_module
소스파일:mod_authz_host.c
지원:아파치 2.1 이후부터
+

요약

+ +

<Directory>, + <Files>, + <Location> + 섹션과 .htaccess + 파일에서 서버의 특정 부분의 접근을 제어하기위해 + mod_authz_host가 제공하는 지시어를 사용한다. + 클라이언트의 호스트명, IP 주소, 환경변수에 기록된 요청의 특성에 따라 + 접근을 제어한다. Allow와 Deny 지시어는 어떤 + 클라이언트가 서버에 접근할 수 있는지를 지시하고, Order 지시어는 기본적으로 + 접근을 허용할지 거부할지 여부와 어떻게 Allow 지시어와 Deny 지시어가 서로 영향을 + 미치는지 결정한다.

+ +

호스트기반 접근제한과 암호기반 인증을 동시에 사용할 수도 + 있다. 이 경우 Satisfy + 지시어를 사용하여 어떻게 두 제한이 서로 영향을 미치는지 + 결정한다.

+ +

일반적으로 접근제한 지시어는 (GET, + PUT, POST 등) 모든 메서드에 적용되며, + 이 행동은 대부분의 경우 바람직하다. 그러나 <Limit> 섹션안에 + 지시어를 사용하여 특정 메서드에만 제한할 수 있다.

+
+

지시어들

+ +

참고

+
+ +
top
+

Allow 지시어

+ + + + + + + +
설명:서버의 일부에 접근할 수 있는 호스트를 지정한다
문법: Allow from all|host|env=env-variable +[host|env=env-variable] ...
사용장소:directory, .htaccess
Override 옵션:Limit
상태:Base
모듈:mod_authz_host
+

Allow 지시어는 어떤 호스트가 서버의 + 일부에 접근할 수 있는지 지시한다. 호스트명, IP 주소, IP + 주소영역, 환경변수에 기록된 다른 특성에 따라 접근을 조절할 + 수 있다.

+ +

이 지시어의 첫번째 아규먼트는 항상 from이다. + 다음 아규먼트에는 세가지 형식이 있다. Allow from all을 + 사용하면, 아래에서 설명할 Deny와 Order 지시어 설정에 + 따라 모든 호스트의 접근을 허가한다. 특정 호스트만 서버로 + 접근을 허용하려면 다음과 같은 형식으로 host를 지시할 + 수 있다:

+ +
+
호스트명 (일부)
+ +
+

예제:

+ Allow from apache.org +

+

호스트명이 이 문자열과 같거나 이 문자열로 끝나면 접근을 + 허용한다. 그래서 이 경우 foo.apache.org는 + 해당되고, fooapache.org는 해당되지 않는다. + 이 설정을 사용하면 아파치는 HostnameLookups 지시어 설정과 + 관계없이 클라이언트 IP 주소를 가지고 중복-역 DNS 검색을 + 한다. 즉, 호스트명을 찾기위해 IP 주소를 역DNS 검색을 한 + 후, 다시 호스트명으로 검색하여 원래 IP 주소와 일치하는지 + 확인한다. 결과가 같고 호스트명이 설정값에 해당하면, 접근을 + 허용한다.

+ +
IP 주소 전체
+ +
+

예제:

+ Allow from 10.1.2.3 +

+

접근을 허가하는 호스트의 IP 주소

+ +
IP 주소 일부
+ +
+

예제:

+ Allow from 10.1 +

+

서브네트워크로 제한하기위해 IP 주소 앞의 1에서 3 + 바이트.

+ +
네트워크/넷매스크 쌍
+ +
+

예제:

+ Allow from 10.1.0.0/255.255.0.0 +

+

네트워크 a.b.c.d와 넷매스크 w.x.y.z. 더 세밀하게 + 서브네트워크로 제한할때 사용한다.

+ +
네트워크/nnn CIDR 규약
+ +
+

예제:

+ Allow from 10.1.0.0/16 +

+

앞의 경우와 같지만, 상위 nnn개 비트 값이 1인 넷매스크를 + 사용한다.

+
+ +

마지막 세가지 예는 정확히 동일한 호스트들을 지칭한다.

+ +

다음과 같이 IPv6 주소와 IPv6 서브네트워크를 지정할 수도 + 있다:

+ +

+ Allow from fe80::a00:20ff:fea7:ccea
+ Allow from fe80::a00:20ff:fea7:ccea/10 +

+ +

Allow 지시어 아규먼트의 세번째 + 형식은 환경변수 유무에 따라 접근을 + 제어한다. Allow from env=env-variable을 + 사용하면, env-variable 환경변수가 정의된 경우 + 접근을 허가한다. mod_setenvif가 제공하는 + 지시어를 사용하여 클라이언트 요청의 특성에 따라 자유롭게 + 환경변수를 설정할 수 있다. 그러므로 이 지시어를 사용하여 + 클라이언트 User-Agent (브라우저 종류), + Referer, 다른 HTTP 요청 헤더에 따라 접근을 + 허가할 수 있다.

+ +

예제:

+ SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
+ <Directory /docroot>
+ + Order Deny,Allow
+ Deny from all
+ Allow from env=let_me_in
+ + </Directory> +

+ +

이 경우 user-agent 문자열이 KnockKnock/2.0으로 + 시작하는 브라우저의 접근은 허용하고, 나머지는 모두 거부한다.

+ +
+
top
+

Deny 지시어

+ + + + + + + +
설명:서버 접근을 거부할 호스트를 지정한다
문법: Deny from all|host|env=env-variable +[host|env=env-variable] ...
사용장소:directory, .htaccess
Override 옵션:Limit
상태:Base
모듈:mod_authz_host
+

이 지시어를 사용하여 호스트명, IP 주소, 환경변수에 따라 + 서버 접근을 제한할 수 있다. Deny + 지시어의 아규먼트는 Allow 지시어와 동일하다.

+ +
+
top
+

Order 지시어

+ + + + + + + + +
설명:기본적으로 접근을 허용할지 거부할지 여부와 +Allow와 Deny +처리순서를 정한다.
문법: Order ordering
기본값:Order Deny,Allow
사용장소:directory, .htaccess
Override 옵션:Limit
상태:Base
모듈:mod_authz_host
+

Order 지시어는 기본적으로 접근을 + 허용할지 거부할지 여부와 Allow와 Deny 지시어 처리순서를 + 정한다. ordering은 다음 중 하나이다

+ +
+
Deny,Allow
+ +
Deny + 지시어를 Allow + 지시어 보다 먼저 살펴본다. 그리고 기본적으로 접근을 허용한다. + Deny나 + Allow 지시어에 + 해당되지 않는 클라이언트의 접근을 허용한다.
+ +
Allow,Deny
+ +
Allow + 지시어를 Deny 지시어 보다 먼저 + 살펴본다. 그리고 기본적으로 접근을 허용하지 않는다. + Deny나 + Allow 지시어에 + 해당되지 않는 클라이언트의 접근을 거부한다.
+ +
Mutual-failure
+ +
Deny + 목록에는 안나오고 Allow 목록에만 나오는 + 호스트만 접근을 허용한다. Order Allow,Deny와 + 같은 일을 하기때문에 사용하지 않는다.
+
+ +

키워드는 쉼표로만 구분한다; 사이에 공백이 있으면 + 안된다. 모든 경우 Allow와 Deny 모두 살펴봄을 + 명심하라.

+ +

아래 예에서 apache.org 도메인의 모든 호스트의 접근은 + 허용하지만, 다른 호스트는 모두 거부한다.

+ +

+ Order Deny,Allow
+ Deny from all
+ Allow from apache.org +

+ +

아래 예에서 foo.apache.org 하위도메인에 있는 호스트만 + 거부하고, apache.org 도메인에 있는 호스트는 모두 접근을 + 허용한다. 기본적으로 접근을 거부하기때문에 apache.org 도메인에 + 속하지 않는 호스트는 접근을 거부한다.

+ +

+ Order Allow,Deny
+ Allow from apache.org
+ Deny from foo.apache.org +

+ +

반대로 위의 Order를 + Deny,Allow로 변경하면, 모든 호스트의 접근을 + 허용한다. 설정파일에서 지시어가 나오는 순서와 관계없이 + Allow from apache.org를 제일 마지막에 처리하여 + Deny from foo.apache.org의 효과를 무시하기 + 때문이다. 또, 기본적으로 접근을 허가하므로 + apache.org 도메인에 속하지 않는 호스트도 모두 + 접근을 허가한다.

+ +

Order 지시어는 기본적으로 접근을 + 허용할지 거부할지를 정하기때문에 Allow나 Deny 지시어를 사용하지 + 않아도 접근가능 여부에 영향을 준다. 예를 들어,

+ +

+ <Directory /www>
+ + Order Allow,Deny
+ + </Directory> +

+ +

는 기본적으로 접근을 거부하기때문에 + /www 디렉토리에 대한 모든 접근을 거부한다.

+ +

Order 지시어가 정하는 접근 지시어 + 처리순서는 해당 서버설정 처리단계에만 영향을 준다. 즉, + Order 지시어 설정과 관계없이 <Location> 섹션 안에 + 있는 Allow나 + Deny 지시어는 + <Directory> + 섹션이나 .htaccess 파일에 있는 Allow와 Deny 지시어를 모두 처리한 + 후에 처리한다. 설정 섹션들이 결합하는 방법에 대해서는 어떻게 Directory, Location, Files + 섹션이 동작하나 문서를 참고하라.

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_host.xml.ko b/docs/manual/mod/mod_authz_host.xml.ko index 4924034342..00ba9a04c6 100644 --- a/docs/manual/mod/mod_authz_host.xml.ko +++ b/docs/manual/mod/mod_authz_host.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_owner - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_owner

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:파일 소유자를 이용한 권한부여
상태:Extension
모듈명:authz_owner_module
소스파일:mod_authz_owner.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 HTTP 인증에 사용한 사용자 아이디(웹 사용자 + 아이디)를 요청한 파일의 파일시스템 소유자/그룹과 비교하여 + 파일의 접근권한을 부여한다. 여기서 사용자명과 암호는 이미 + mod_auth_basic이나 + mod_auth_digest 같은 인증모듈의 확인을 + 거쳤다. mod_authz_owner는 Require 지시어의 다음 두 아규먼트, + file-owner와 file-group을 처리한다:

+ +
+
file-owner
+
웹 사용자명이 요청한 파일 소유자의 시스템 이름과 같아야 + 한다. 즉, 운영체제가 요청한 파일의 소유자가 + jones라면, 웹을 통해 파일에 접근하는 사용자도 + 마찬가지로 jones이어야 한다.
+ +
file-group
+
파일을 소유한 시스템 그룹명이 + mod_authz_groupfile이나 + mod_authz_dbm과 같은 그룹 데이터베이스에 + 있고, 웹 사용자명이 해당 그룹에 속해야 한다. 예를 들어, + 운영체제가 요청한 파일을 accounts (시스템) + 그룹이 소유하고 있다면, 그룹 데이터베이스에 + accounts라는 그룹이 있고 요청에 사용한 웹 + 사용자명이 그 그룹에 속해야 한다.
+
+ +

주의

+

mod_authz_owner가 실제로 파일시스템에 + 있지 않는 자원을 (즉, 가상 자원) 권한부여한다면, + 접근을 거부한다.

+ +

특히 내용협상한 + "MultiViews" 자원을 권한부여하지 않는다.

+
+
+

지시어들

+ +

주제

+

참고

+
+
top
+
+

설정 예제

+ +

Require file-owner

+

아파치 웹서버를 운영하는 다중사용자 시스템에서 각 사용자가 + ~/public_html/private에 자신의 파일을 저장한다고 + 가정하자. 모든 웹 사용자명을 저장하는 AuthDBMUserFile + 데이터베이스가 있고, 여기에 저장된 사용자명은 서버에서 + 실제 파일을 소유하는 시스템 사용자명과 동일하다. 이 경우 + 아래 설정은 파일 소유자에게만 접근을 허용한다. 사용자 + jones는 파일을 jones가 아닌 + smith가 소유하고 있는 한 + /home/smith/public_html/private에 있는 파일에 + 접근할 수 없다.

+ +

+ <Directory /home/*/public_html/private>
+ + AuthType Basic
+ AuthName MyPrivateFiles
+ AuthBasicProvider dbm
+ AuthDBMUserFile /usr/local/apache2/etc/.htdbm-all
+ Satisfy All
+ Require file-owner
+ + </Directory> +

+ + +

Require file-group

+

위와 상황이 비슷하지만 여러명이 + ~/public_html/project-foo에 프로젝트 파일을 + 공유한다고 가정하자. 파일들은 시스템 그룹 foo가 + 소유하며, 모든 웹 사용자명과 사용자 그룹을 기록하는 AuthDBMGroupFile + 데이터베이스가 있다. 즉, 최소한 foo라는 + 그룹에 구성원이 있다. jones와 + smith가 모두 그룹 foo의 + 구성원이라면, 둘 모두 project-foo 디렉토리에 + 접근할 수 있다.

+ +

+ <Directory /home/*/public_html/project-foo>
+ + AuthType Basic
+ AuthName "Project Foo Files"
+ AuthBasicProvider dbm
+
+ # combined user/group database
+ AuthDBMUserFile /usr/local/apache2/etc/.htdbm-all
+ AuthDBMGroupFile /usr/local/apache2/etc/.htdbm-all
+
+ Satisfy All
+ Require file-group
+ + </Directory> +

+ +
+
top
+

AuthzOwnerAuthoritative 지시어

+ + + + + + + + +
설명:권한부여를 저수준 모듈로 넘겨줄지 여부
문법:AuthzOwnerAuthoritative On|Off
기본값:AuthzOwnerAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Extension
모듈:mod_authz_owner
+

AuthzOwnerAuthoritative 지시어를 + 직접 Off로 설정하면 다음과 같은 경우 사용자 + 권한부여를 (modules.c 파일에서 정의한) 저수준 + 모듈로 넘겨준다.

+ + + +

또, 값을 Off로 설정하면 + file-owner와 file-group을 결합하여, + 둘 중 하나만 만족해도 접근을 허가한다.

+ +

기본적으로 제어를 넘기지않고, 모르는 그룹의 경우 인증 + 필요 응답을 한다. 이 지시어를 Off로 설정하지않으면 + 시스템이 안전하게 유지되며, NCSA 웹서버와 같이 동작한다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_owner.xml.ko b/docs/manual/mod/mod_authz_owner.xml.ko index d2850c0daf..403a448bd5 100644 --- a/docs/manual/mod/mod_authz_owner.xml.ko +++ b/docs/manual/mod/mod_authz_owner.xml.ko @@ -1,7 +1,7 @@ - + +mod_authz_user - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_authz_user

+
+

가능한 언어:  en  | + ko 

+
+ + + + +
설명:사용자 권한부여
상태:Base
모듈명:authz_user_module
소스파일:mod_authz_user.c
지원:아파치 2.1 이후부터
+

요약

+ +

이 모듈은 권한을 부여하여, 인증한 사용자가 웹사이트의 + 일부에 접근할 수 있는지 결정한다. + mod_authz_user는 Require user + 지시어 목록에 인증한 사용자가 들어있으면 접근을 허용한다. + 또, require valid-user는 성공적으로 인증한 + 사용자 모두에게 접근을 허용한다.

+
+

지시어들

+ +

참고

+
+ +
top
+

AuthzUserAuthoritative 지시어

+ + + + + + + + +
설명:권한부여를 저수준 모듈로 넘겨줄지 여부
문법:AuthzUserAuthoritative On|Off
기본값:AuthzUserAuthoritative On
사용장소:directory, .htaccess
Override 옵션:AuthConfig
상태:Base
모듈:mod_authz_user
+

AuthzUserAuthoritative 지시어를 + 직접 Off로 설정하면 해당 사용자가 + 없는 경우 사용자 권한부여를 (modules.c + 파일에서 정의한) 저수준 모듈로 넘겨준다.

+ +

기본적으로 제어를 넘기지않고, 모르는 사용자의 경우 인증 + 필요 응답을 한다. 이 지시어를 Off로 설정하지않으면 + 시스템이 안전하게 유지되며, NCSA 웹서버와 같이 동작한다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authz_user.xml.ko b/docs/manual/mod/mod_authz_user.xml.ko index 3f703b1fbb..c5f60763fa 100644 --- a/docs/manual/mod/mod_authz_user.xml.ko +++ b/docs/manual/mod/mod_authz_user.xml.ko @@ -1,7 +1,7 @@ - + +mod_example - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_example

+
+

가능한 언어:  en  | + ko 

+
+ + + +
설명:아파치 모듈 API를 설명한다
상태:Experimental
모듈명:example_module
소스파일:mod_example.c
+

요약

+ +

아파치 배포본 modules/experimental 디렉토리에 + 있는 파일들은 아파치 API를 사용하여 모듈을 작성하려는 사람들을 + 돕기위한 예제다.

+ +

mod_example.c는 모든 콜백(callback) 구조와 + 호출 문법을 설명하는 파일이다. 당신은 모듈에 이 모든 콜백을 + 구현할 필요가 없다. 사실 정반대다!

+ +

example 모듈은 실제로 동작하는 모듈이다. 이 모듈을 서버에 + 연결하고 특정 위치에 "example-handler" 핸들러를 할당하여 + 그곳을 브라우징하면 example 모듈의 여러 콜백을 확인할 수 + 있다.

+
+

지시어들

+ +

주제

+
+
top
+
+

example 모듈 컴파일하기

+ +

서버에 example 모듈을 포함하려면 다음 과정을 거친다:

+ +
    +
  1. + --enable-example 옵션과 함께 + configure를 실행한다.
    2. + +
  2. 서버를 컴파일한다 ("make"를 실행한다).
    3. +
+ +

자신이 만든 모듈을 추가하려면:

+ +
    +
  1. cp modules/experimental/mod_example.c + modules/new_module/mod_myexample.c
    2. + +
  2. 파일을 수정한다.
    3. + +
  3. modules/new_module/config.m4 파일을 만든다. +
      +
    1. APACHE_MODPATH_INIT(new_module)을 + 추가한다.
      2. +
    2. modules/experimental/config.m4 파일에서 + "example"이 있는 APACHE_MODULE 줄을 복사해온다.
      3. +
    3. 첫번째 아규먼트 "example"을 myexample로 + 변경한다.
      4. +
    4. 두번째 아규먼트 자리에 자신이 만든 모듈에 대한 + 간단한 설명을 적는다. configure --help를 + 실행하면 여기에 기록한 설명을 보여준다.
      5. +
    5. 모듈을 컴파일할때 특별한 C 컴파일러 옵션, 링커 + 옵션, 라이브러리가 필요하면 각각 CFLAGS, LDFLAGS, + LIBS에 추가한다. modules 디렉토리에 있는 다른 + config.m4 파일들을 참고하라.
      6. +
    6. APACHE_MODPATH_FINISH를 추가한다.
      7. +
    +
    4. + +
  4. module/new_module/Makefile.in 파일을 + 만든다. 모듈을 컴파일하는데 특별한 명령어가 필요없다면, + 파일에 include $(top_srcdir)/build/special.mk만 + 있어도 된다.
    5. + +
  5. 최상위 디렉토리에서 ./buildconf 를 실행한다.
    6. + +
  6. --enable-myexample 옵션을 사용하여 서버를 컴파일한다
    7. + +
+
top
+
+

mod_example 모듈 사용하기

+ +

example 모듈을 사용하려면 httpd.conf 파일에 + 다음과 같은 설정을 추가하라:

+

+ <Location /example-info>
+ SetHandler example-handler
+ </Location> +

+ +

아니면 .htaccess + 파일에 다음과 같은 내용을 추가하고, 그 위치에서 "test.example" + 같은 파일을 요청하라:

+

+ AddHandler example-handler .example +

+ +

서버를 재시작한 후 이 위치를 브라우징하면 앞에서 말한 + 내용을 보게될 것이다.

+
+
top
+

Example 지시어

+ + + + + + +
설명:아파치 모듈 API를 설명하기위한 예제 지시어
문법:Example
사용장소:주서버설정, 가상호스트, directory, .htaccess
상태:Experimental
모듈:mod_example
+

Example 지시어는 example 모듈의 + 내용핸들러가 간단한 문구를 보일지 여부를 설정한다. 이 지시어는 + 아규먼트를 받지않는다. example 내용핸들러를 적용한 URL에 + 접속하면 문서 요청을 서비스하기위해 모듈안에 함수들이 어떻게 + 그리고 어떤 순서로 불리는지 알 수 있다. 이 지시어의 효과는 + "Example directive declared here: YES/NO"로 + 확인할 수 있다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_example.xml.ko b/docs/manual/mod/mod_example.xml.ko index 0ab612d43f..31c749793b 100644 --- a/docs/manual/mod/mod_example.xml.ko +++ b/docs/manual/mod/mod_example.xml.ko @@ -1,7 +1,7 @@ - + +mod_expires - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_expires

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:사용자가 지정한 기준에 따라 Expires +HTTP 헤더를 생성한다
상태:Extension
모듈명:expires_module
소스파일:mod_expires.c
+

요약

+ +

이 모듈은 서버 응답의 Expires HTTP 헤더 + 설정을 조절한다. 만기일을 소스파일이 마직막 수정될 시간 + 혹은 클라이언트가 접속한 시간에 상대적으로 설정할 수 있다.

+ +

Expires HTTP 헤더는 클라이언트에게 문서의 + 유효성과 지속성을 알려준다. 이 시간이 아직 지나지않았다면, + 문서를 캐쉬에서 가져와도 된다. 만기일이 지났다면 캐쉬된 + 것을 "만료되고" 유효하지 않다고 간주하여, 소스에서 문서를 + 새로 얻어와야 한다.

+
+

지시어들

+ +

주제

+
+
top
+
+

다른 내부 문법

+

ExpiresDefault와 + ExpiresByType + 지시어를 더 읽기 좋은 형식으로 기술할 수 있다:

+ +

+ ExpiresDefault "<base> [plus] {<num> + <type>}*"
+ ExpiresByType type/encoding "<base> [plus] + {<num> <type>}*" +

+ +

<base>는 다음중 하나이다:

+ + + +

plus 키워드는 없어도 된다. <num>은 + [atoi()에 사용할 수 있는] 정수값이다. + <type>은 다음중 하나이다:

+ + + +

예를 들어, 다음 모두는 문서가 기본적으로 접속된지 1달후에 + 만기된다고 설정한다:

+ +

+ ExpiresDefault "access plus 1 month"
+ ExpiresDefault "access plus 4 weeks"
+ ExpiresDefault "access plus 30 days" +

+ +

'<num> <type>' 구문을 반복해서 사용하여 + 만기시간을 자세히 설정할 수 있다:

+ +

+ ExpiresByType text/html "access plus 1 month 15 + days 2 hours"
+ ExpiresByType image/gif "modification plus 5 hours 3 + minutes" +

+ +

만약 수정시간(modification)을 기준으로 만기시간을 설정하는 + 경우 내용을 디스크에 있는 파일에서 가져오지 않는다면 Expires + 헤더를 붙이지 않는다. 이 경우 내용에 수정시간이 + 없기 때문이다.

+
+
top
+

ExpiresActive 지시어

+ + + + + + + +
설명:Expires 헤더를 생성한다
문법:ExpiresActive On|Off
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:Indexes
상태:Extension
모듈:mod_expires
+

이 지시어는 해당 영역에 대해 (즉, .htaccess + 파일에서 사용한다면 그 디렉토리 아래에 있는 문서들만 해당된다.) + Expires 헤더를 생성할지 유무를 결정한다. + (.htaccess 파일 등으로 더 하위 단계에서 서버설정을 + 변경하지않는 한) Off이면 해당 영역에 있는 + 문서에 Expires 헤더를 생성하지 않는다. + On이면 ExpiresByType과 ExpiresDefault 지시어로 + (해당 항목을 참고하라) 지정한 규칙에 따라 서비스하려는 + 문서에 헤더를 생성한다.

+ +

이 지시어는 Expires 헤더를 보장하지 않는다. + 규칙에 해당하지 않다면 마치 이 지시어가 없는 것처럼 헤더를 + 만들지 않는다.

+ +
+
top
+

ExpiresByType 지시어

+ + + + + + + +
설명:MIME type으로 Expires 헤더값을 설정한다
문법:ExpiresByType MIME-type +<code>seconds
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:Indexes
상태:Extension
모듈:mod_expires
+

이 지시어는 특정 종류의 (에를 들어, + text/html) 문서에 대한 Expires + 헤더값을 정의한다. 두번째 아규먼트는 만기시간을 결정할때 + 기준 시간에 더할 초단위 값을 지정한다.

+ +

기준 시간은 파일의 최근 수정시간 혹은 클라이언트가 문서에 + 접근한 시간이다. 이떤 것을 사용할지는 + <code> 필드로 결정해야 한다. + M은 기준 시간으로 파일의 최근 수정시간을 + 사용하고, A는 클라이언트의 접근 시간을 사용한다.

+ +

차이는 미묘하다. M을 사용하면 캐쉬에 있는 + 모든 복사본이 같은 시간에 만료된다. 그래서 항상 같은 URL로 + 찾아볼 수 있는 주간일정 같은 용도에 좋다. A를 + 사용하면 복사본의 만기시간이 각각 다르다. 이는 자주 수정되지않는 + 그림파일에, 특히 여러 문서에서 같은 그림을 참조할때 (예를 + 들어, 이미지는 상대적으로 짧은 기간동안 반복해서 접근된다), + 유용하다.

+ +

예제:

+ # 만기헤더를 사용한다
+ ExpiresActive On
+ # 클라이언트 캐쉬의 GIF 그림은 한 달후에 만기한다
+ ExpiresByType image/gif A2592000
+ # HTML 문서는 변경후 일주일간 유효하다 + ExpiresByType text/html M604800 +

+ +

이 지시어는 ExpiresActive On을 사용할때만 + 유효함을 주의하라. ExpiresDefault 지시어를 + 사용하여 특정 MIME type에 대해서만 만기시간을 + 설정할 수 있다.

+ +

앞에서 설명한 다른 문법을 사용하여 + 만기시간을 계산할 수도 있다.

+ +
+
top
+

ExpiresDefault 지시어

+ + + + + + + +
설명:만기시간을 계산하는 기본 알고리즘
문법:ExpiresDefault <code>seconds
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:Indexes
상태:Extension
모듈:mod_expires
+

이 지시어는 해당 영역에 있는 모든 문서의 만기시간을 + 계산하는 기본 알고리즘을 지정한다. ExpiresByType 지시어를 + 사용하여 종류별로 설정할 수 있다. 아규먼트 문법에 대한 + 자세한 설명은 그 지시어와 다른 문법을 + 참고하라.

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_expires.xml.ko b/docs/manual/mod/mod_expires.xml.ko index 61913ee08c..a8585f6843 100644 --- a/docs/manual/mod/mod_expires.xml.ko +++ b/docs/manual/mod/mod_expires.xml.ko @@ -1,7 +1,7 @@ - + +mod_ext_filter - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_ext_filter

+
+

가능한 언어:  en  | + ko 

+
+ + + +
설명:응답 내용을 외부 프로그램으로 처리한 후 클라이언트로 +보낸다
상태:Extension
모듈명:ext_filter_module
소스파일:mod_ext_filter.c
+

요약

+ +

mod_ext_filter를 사용하면 간단하고 익숙한 + 방법으로 필터를 만들 수 있다. + 표준입력에서 읽고 표준출력에 쓰는 프로그램(즉, 유닉스식 + 필터 명령어)을 아파치 필터로 사용할 수 있다. 이런 필터는 + 아파치 API로 쓰여지고 아파치 서버 프로세스 안에서 실행되는 + 필터에 비해 매우 느리지만, 다음과 같은 장점이 있다:

+ + + +

실제 사용하기에는 성능이 떨어지지만, + mod_ext_filter를 사용하여 필터를 빨리 만들어볼 + 수 있다.

+ +
+

지시어들

+ +

주제

+

참고

+
+
top
+
+

예제

+ +

다른 type의 응답을 HTML로 만든다

+

+ # mod_ext_filter 지시어를 가지고
+ # 외부 프로그램 /usr/bin/enscript를 사용하여
+ # 문서파일과 text/c 파일을 HTML로 만들고 결과의
+ # type을 text/html로 변경하는 필터를 정의한다
+ ExtFilterDefine c-to-html mode=output \
+ + intype=text/c outtype=text/html \
+ cmd="/usr/bin/enscript --color -W html -Ec -o - -"
+ +
+ <Directory "/export/home/trawick/apacheinst/htdocs/c">
+ + # 출력에 새로운 필터를 실행하는 core 지시어
+ SetOutputFilter c-to-html
+
+ # .c 파일의 type을 text/c로 만드는 mod_mime
+ # 지시어
+ AddType text/c .c
+
+ # 디버그 수준을 높여서 요청마다 현재 설정을
+ # 알려주는 로그문을 기록하는 mod_ext_filter
+ # 지시어
+ ExtFilterOptions DebugLevel=1
+ + </Directory> +

+ + +

content 인코딩 필터 구현하기

+

Note: 아래 gzip 예제는 단지 설명을 예로 든 것이다. + 실제 서비스에 사용하려면 mod_deflate를 + 참고하길 바란다.

+ +

+ # 외부 필터를 정의하는 mod_ext_filter 지시어
+ ExtFilterDefine gzip mode=output cmd=/bin/gzip
+
+ <Location /gzipped>
+ + # 출력할때 gzip 필터를 실행하는 core 지시어
+ SetOutputFilter gzip
+
+ # "Content-Encoding: gzip" 헤더를 추가하는
+ # mod_header 지시어
+ Header set Content-Encoding gzip
+ + </Location> +

+ + +

서버를 느리게 하기

+

+ # cat으로 모든 내용을 통과하는 필터를 정의하는
+ # mod_ext_filter 지시어; cat은 아무것도 수정하지
+ # 않는다; 단지 처리경로를 길게 하여 자원을 더 소모한다
+ ExtFilterDefine slowdown mode=output cmd=/bin/cat \
+ + preservescontentlength
+ +
+ <Location />
+ + # 출력할때 slowdown 필터를 여러번 실행하는 core 지시어
+ #
+ SetOutputFilter slowdown;slowdown;slowdown
+ + </Location> +

+ + +

sed를 사용하여 응답에서 글을 대체하기

+

+ # 응답에서 글을 대체하는 필터를 정의하는
+ # mod_ext_filter 지시어
+ #
+ ExtFilterDefine fixtext mode=output intype=text/html \
+ + cmd="/bin/sed s/verdana/arial/g"
+ +
+ <Location />
+ + # 출력할때 fixtext 필터를 실행하는 core 지시어
+ SetOutputFilter fixtext
+ + </Location> +

+ + +

다른 필터를 추적하기

+

+ # 압축 문제가 있는 특정 클라이언트(IP 192.168.1.31)에
+ # 대해 mod_deflate가 읽고 쓰는 자료를 추적한다.
+ # 이 필터는 mod_deflate로 보내기 전 자료를 추적한다.
+ ExtFilterDefine tracebefore \
+ + cmd="/bin/tracefilter.pl /tmp/tracebefore" \
+ EnableEnv=trace_this_client
+ +
+ # 이 필터는 mod_deflate에서 나오는 자료를 추적한다.
+ # ftype 파라미터를 사용하지않는 경우, 기본 필터형
+ # AP_FTYPE_RESOURCE는 필터 순서를 mod_deflate *이전에*
+ # 둔다. AP_FTYPE_CONTENT_SET 보다 조금 높은 숫자값을
+ # 지정하면 mod_deflate 이후에 실행한다.
+ ExtFilterDefine traceafter \
+ + cmd="/bin/tracefilter.pl /tmp/traceafter" \
+ EnableEnv=trace_this_client ftype=21
+ +
+ <Directory /usr/local/docs>
+ + SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
+ SetOutputFilter tracebefore;deflate;traceafter
+ + </Directory> +

+ +

다음은 자료를 추적하는 필터이다:

+ #!/usr/local/bin/perl -w
+ use strict;
+
+ open(SAVE, ">$ARGV[0]")
+ + or die "can't open $ARGV[0]: $?";
+ +
+ while (<STDIN>) {
+ + print SAVE $_;
+ print $_;
+ + }
+
+ close(SAVE); +

+ +
+
top
+

ExtFilterDefine 지시어

+ + + + + + +
설명:외부 필터를 정의한다
문법:ExtFilterDefine filtername parameters
사용장소:주서버설정
상태:Extension
모듈:mod_ext_filter
+

ExtFilterDefine 지시어는 외부 + 필터의 성질과 실행할 프로그램, 아규먼트를 정의한다.

+ +

filtername은 정의할 필터 이름을 지정한다. + 이 이름을 SetOutputFilter 지시어에서 사용한다. 등록한 모든 + 필터들간에 이름이 겹치면 안된다. 현재 필터등록 API는 + 오류를 보고하지 않는다. 그래서 사용자는 이름이 겹치는 문제를 + 알지 못한다.

+ +

실행할 외부 명령어와 다른 성질을 정의하는 나머지 아규먼트는 + 어떤 순서로 나와도 가능하다. 단, cmd= 파라미터는 + 반드시 필요하다. 사용할 수 있는 파라미터는 다음과 같다:

+ +
+
cmd=cmdline
+ +
cmd= 키워드는 실행할 외부 명령어를 지정한다. + 프로그램명 뒤에 아규먼트가 있다면 명령행을 쌍따옴표로 + 묶어야 한다 (예를 들어, + cmd="/bin/mypgm arg1 + arg2"). 쉘을 거치지않고 직접 프로그램을 + 실행하기때문에 일반적인 쉘 따옴표는 필요없다. 프로그램 + 아규먼트들은 공백으로 구분한다. 프로그램 아규먼트에 공백이 + 있다면 공백 앞에 백슬래쉬로 사용해야 한다. 백슬래쉬가 + 아규먼트의 일부라면 백슬래쉬를 두번 사용해야 한다. 프로그램을 + 실행할때 표준 CGI 환경변수와 추가로 DOCUMENT_URI, + DOCUMENT_PATH_INFO, QUERY_STRING_UNESCAPED 변수를 설정한다.
+ +
mode=mode
+ +
응답을 처리하는 필터는 (기본값인) mode=output을 + 사용한다. 요청을 처리하는 필터는 mode=input을 + 사용한다. mode=input은 아파치 2.1에 추가되었다.
+ +
intype=imt
+ +
이 파라미터는 필터로 처리할 문서의 인터넷 media + type(즉, MIME type)을 지정한다. 기본적으로 모든 + 문서를 필터로 처리한다. intype=을 지정하면 + 다른 type의 문서는 필터로 처리하지 않는다.
+ +
outtype=imt
+ +
이 파라미터는 필터로 처리한 문서의 인터넷 media + type(즉, MIME type)을 지정한다. 필터처리 작업중에 + 인터넷 media type을 변경할때 유용하다. 기본적으로, 인터넷 + media type은 변하지 않는다.
+ +
PreservesContentLength
+ +
PreservesContentLength 키워드는 필터가 + content length를 유지하도록 한다. 대부분의 필터가 content + length를 변경하므로 이 키워드는 기본값이 아니다. 필터가 + 길이를 유지할때만 이 키워드를 사용해야 한다.
+ +
ftype=filtertype
+ +
이 파라미터는 필터 종류에 대한 숫자값을 지정한다. + 대부분의 경우 기본값인 AP_FTYPE_RESOURCE가 적당하다. + 필터를 실행하는 순서가 자원필터와 달라야하는 경우 이 + 파라미터가 필요하다. 적당한 값을 알려면 util_filter.h에 + 있는 AP_FTYPE_* 정의를 참고하라.
+ +
disableenv=env
+ +
이 파라미터로 설정한 환경변수가 정의되었다면 필터를 + 사용하지 않는다.
+ +
enableenv=env
+ +
이 파라미터로 설정한 환경변수가 정의된 경우 필터를 + 사용한다.
+
+ +
+
top
+

ExtFilterOptions 지시어

+ + + + + + + +
설명:mod_ext_filter 옵션을 설정한다
문법:ExtFilterOptions option [option] ...
기본값:ExtFilterOptions DebugLevel=0 NoLogStderr
사용장소:directory
상태:Extension
모듈:mod_ext_filter
+

ExtFilterOptions 지시어는 + mod_ext_filter의 특별한 처리옵션을 지정한다. + Option은 다음중 하나다.

+ +
+
DebugLevel=n
+ +
+ DebugLevel 키워드는 + mod_ext_filter가 기록하는 디버그 문구 + 수준을 정한다. 기본값은 디버그문을 기록하지 않는다. + 이는 DebugLevel=0과 같다. 높은 숫자를 + 사용할수록, 더 많은 디버그문이 기록되고 서버 성능이 + 떨어진다. 숫자값의 실제 의미는 mod_ext_filter.c + 앞부분에 있는 DBGLVL_ 상수 정의에 설명되있다. + +

주의: 필터 로그를 기록하려면 core 지시어 LogLevel을 사용하여 디버그문을 + 아파치 오류로그에 기록해야 한다.

+
+ +
LogStderr | NoLogStderr
+ +
LogStderr 키워드는 외부 필터 프로그램이 + 표준오류로 출력하는 문구를 아파치 오류로그에 기록한다. + NoLogStderr는 이 기능을 하지 않는다.
+
+ +

예제

+ ExtFilterOptions LogStderr DebugLevel=0 +

+ +

위의 설정을 사용하면 필터가 표준오류로 출력하는 문구를 + 아파치 오류로그에 기록하고, mod_ext_filter는 + 자체 디버그문을 기록하지 않는다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_ext_filter.xml.ko b/docs/manual/mod/mod_ext_filter.xml.ko index 60bf1ed90e..cd392c2c0b 100644 --- a/docs/manual/mod/mod_ext_filter.xml.ko +++ b/docs/manual/mod/mod_ext_filter.xml.ko @@ -1,7 +1,7 @@ - + +mod_file_cache - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_file_cache

+
+

가능한 언어:  en  | + ko 

+
+ + + +
설명:메모리에 정적 파일들을 캐쉬
상태:Experimental
모듈명:file_cache_module
소스파일:mod_file_cache.c
+

요약

+ + +
+ 이 모듈은 조심해서 사용해야 한다. mod_file_cache를 +사용하여 사이트를 망치기 쉬우므로 이 문제를 꼼꼼히 읽어라. +
+ +

거의 변하지 않고 자주 요청되는 파일을 캐쉬에 저장하여 +서버 부하를 줄일 수 있다. mod_file_cache는 +두가지 방식으로 자주 요청되는 정적 파일을 캐쉬에 저장한다. +설정 지시어를 통해 mod_file_cache가 파일을 +열고(open) mmap()할지 파일을 미리 열고 +파일 핸들러를 저장할지 결정한다. 두 방식 모두 +파일을 서비스하기위한 작업의 일부를 ((특히 파일 입출력) 파일 요청때마다 +하는 대신 서버가 시작할때 하여 서버 부하를 감소한다.

+ +

주의: 이 방법은 CGI 프로그램이나 특별한 내용핸들러를 통해 서비스하는 +파일의 속도를 향상할 수 없다. 이 방법은 보통 아파치 core 내용핸들러가 +서비스하는 일반파일에만 적용된다.

+ +

이 모듈은 아파치 1.3의 mod_mmap_static 모듈의 +영향을 많이 받은 확장이다.

+
+

지시어들

+ +

주제

+
+
top
+
+

mod_file_cache 사용하기

+ +

mod_file_cache는 주서버 설정에서 +MMapFile과 CacheFile 지시어를 통해 설정한 정적 파일들을 +캐쉬에 저장한다.

+ +

모든 플래폼이 두 지시어를 모두 지원하는 것은 아니다. +예를 들어, 윈도우즈용 아파치는 현재 MMapStatic 지시어를 +지원하지 않지만, AIX 같은 다른 플래폼은 둘 모두 지원한다. +지원하지않는 지시어를 사용할 경우 서버 오류 로그에 오류문을 +남긴다. 지원하지않는 지시어를 사용해도 서버는 시작하지만 +파일을 캐쉬에 저장하지 않는다. 두 지시어를 모두 지원하는 플래폼을 +사용한다면 어떤 방식이 더 좋은지 실험해볼 수 있다.

+ +

MMapFile 지시어

+ +

mod_file_cache의 +MMapFile 지시어는 +설정한 정적인 파일들을 mmap() 시스템호출을 사용하여 +메모리에 대응한다. 많은 최근 유닉스류 운영체제에 이 시스템호출이 +있지만, 없는 운영체제도 있다. 또, mmap()할 수 있는 +파일 크기와 개수를 시스템이 제한할 수 있으므로 실험해보는 것이 +좋다.

+ +

서버가 시작할때와 재시작할때만 mmap()을 +한다. 그래서 파일시스템에서 해당 파일중 하나라도 변경된 경우 +서버를 재시작해야 한다 (Stopping and Restarting 문서 참고). +다시 강조하면: 서버를 재시작하지않고 파일을 수정하면 +요청 서비스가 완전히 이상할 수 있다. 이전 파일을 지우고(unlink) +새로 파일을 만들어서 파일을 수정해야 한다. rdist나 +mv와 같이 많은 도구가 이런 식으로 동작한다. +매번 추가로 불필요한 stat() 검사가 필요하고 +입출력 감소의 의도에 반하므로 이 모듈은 파일 변화를 신경쓰지않는다.

+ + +

CacheFile 지시어

+ +

mod_file_cache의 +CacheFile 지시어는 +설정 지시어에 열거한 +파일(과 파일들)의 핸들(handle) 혹은 +파일 기술자(file descriptor)를 열고(open) 캐쉬에 저장한다. +파일을 요청하면 서버는 캐쉬에서 핸들을 찾아서 소켓 API +sendfile()에 (윈도우즈에서는 TransmitFile()) +넘긴다.

+ + + +

서버가 시작할때와 재시작할때만 이런 파일핸들 캐쉬를 +만든다. ... +This file handle caching is done once at server start or + restart, only. So whenever one of the cached files changes on + the filesystem you have to restart the server (see the + Stopping and Restarting + documentation). To reiterate that point: if the files are + modified in place without restarting the server you + may end up serving requests that are completely bogus. You + should update files by unlinking the old copy and putting a new + copy in place. Most tools such as rdist and + mv do this.

+ + +

주의

+

디렉토리의 모든 파일을 재귀적으로 캐쉬에 저장하는 +지시어를 요구하지 마라. 대신 이렇게 해봐라... +Include 지시어를 참고하고 +다음과 같은 명령을 실행하라:

+ +

+ find /www/htdocs -type f -print \
+ | sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf +

+
+
+
top
+

CacheFile 지시어

+ + + + + + +
설명:Cache a list of file handles at startup time
문법:CacheFile file-path [file-path] ...
사용장소:주서버설정
상태:Experimental
모듈:mod_file_cache
+

The CacheFile directive opens handles to + one or more files (given as whitespace separated arguments) and + places these handles into the cache at server startup + time. Handles to cached files are automatically closed on a server + shutdown. When the files have changed on the filesystem, the + server should be restarted to to re-cache them.

+ +

Be careful with the file-path arguments: They have + to literally match the filesystem path Apache's URL-to-filename + translation handlers create. We cannot compare inodes or other + stuff to match paths through symbolic links etc. + because that again would cost extra stat() system + calls which is not acceptable. This module may or may not work + with filenames rewritten by mod_alias or + mod_rewrite.

+ +

Example

+ CacheFile /usr/local/apache/htdocs/index.html +

+ +
+
top
+

MMapFile 지시어

+ + + + + + +
설명:Map a list of files into memory at startup time
문법:MMapFile file-path [file-path] ...
사용장소:주서버설정
상태:Experimental
모듈:mod_file_cache
+

The MMapFile directive maps one or more files + (given as whitespace separated arguments) into memory at server + startup time. They are automatically unmapped on a server + shutdown. When the files have changed on the filesystem at + least a HUP or USR1 signal should be send to + the server to re-mmap() them.

+ +

Be careful with the file-path arguments: They have + to literally match the filesystem path Apache's URL-to-filename + translation handlers create. We cannot compare inodes or other + stuff to match paths through symbolic links etc. + because that again would cost extra stat() system + calls which is not acceptable. This module may or may not work + with filenames rewritten by mod_alias or + mod_rewrite.

+ +

Example

+ MMapFile /usr/local/apache/htdocs/index.html +

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_file_cache.xml.ko b/docs/manual/mod/mod_file_cache.xml.ko index 0bbcc2a346..318f546981 100644 --- a/docs/manual/mod/mod_file_cache.xml.ko +++ b/docs/manual/mod/mod_file_cache.xml.ko @@ -1,7 +1,7 @@ - + +mod_logio - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_logio

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:요청당 입출력 바이트수를 기록
상태:Extension
모듈명:logio_module
소스파일:mod_logio.c
+

요약

+ + +

이 모듈은 요청당 입출력 바이트수를 기록한다. 숫자는 + 네트웍에서 실제로 주고받은 바이트수를 나타내며, 요청과 응답의 + 헤더와 내용을 포함한다. 개수는 입력의 경우 SSL/TLS 이전에, + 출력의 경우 SSL/TLS 이후에 세기때문에 암호화의 결과도 + 올바로 반영된다.

+ +

이 모듈을 사용하려면 mod_log_config이 + 필요하다.

+ +
+

지시어들

+

이 모듈에는 지시어가 없습니다.

+

주제

+

참고

+
+
top
+
+

사용자정의 로그 형식

+ + +

이 모듈은 두가지 새로운 로그지시어를 추가한다. 요청자체의 + 특성은 형식문자열에 "%" 지시어를 사용하여 기록한다. + 지시어는 로그파일에 다음과 같은 값을 기록한다:

+ + + + + + + +
형식문자열설명
%...I요청과 헤더를 포함하여 받은 바이트수. 0일 수 없다.
%...O헤더를 포함하여 보낸 바이트수. 0일 수 없다.
+ +

보통 다음과 같이 사용한다:

+ +
+ +
결합된 입출력 로그 형식:
+ +
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\" %I %O"
+ +
+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_logio.xml.ko b/docs/manual/mod/mod_logio.xml.ko index f1dd8d24c7..f76ca8a1b1 100644 --- a/docs/manual/mod/mod_logio.xml.ko +++ b/docs/manual/mod/mod_logio.xml.ko @@ -1,7 +1,7 @@ - + +mod_setenvif - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_setenvif

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:요청의 성격에 따라 환경변수 설정을 변경한다
상태:Base
모듈명:setenvif_module
소스파일:mod_setenvif.c
+

요약

+ + +

mod_setenvif 모듈은 요청의 성격이 + 정규표현식에 해당하는지 여부로 환경변수를 설정한다. 서버의 + 다른 부분이 행동을 결정할때 이 환경변수를 사용할 수 있다.

+ +

설정파일에 나오는 순서대로 지시어를 처리한다. 그래서 + 브라우저가 MSIE가 아니라 mozilla인 경우 netscape를 + 설정하는 아래 예와 같이 여러 지시어를 함께 사용할 수 있다.

+ +

+ BrowserMatch ^Mozilla netscape
+ BrowserMatch MSIE !netscape
+

+
+

지시어들

+ +

참고

+
+ +
top
+

BrowserMatch 지시어

+ + + + + + + +
설명:HTTP User-Agent에 따라 환경변수를 설정한다
문법:BrowserMatch regex [!]env-variable[=value] +[[!]env-variable[=value]] ...
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_setenvif
+

BrowserMatch는 SetEnvIf 지시어의 특별한 + 경우로, HTTP 요청 헤더 User-Agent에 따라 환경변수를 + 설정한다. 다음 두 줄은 같다:

+

+ BrowserMatchNoCase Robot is_a_robot
+ SetEnvIfNoCase User-Agent Robot is_a_robot
+

+ +

추가 예제:

+

+ BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
+ BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
+ BrowserMatch MSIE !javascript
+

+ +
+
top
+

BrowserMatchNoCase 지시어

+ + + + + + + + +
설명:대소문자를 구별하지않고 User-Agent에 따라 환경변수를 +설정한다
문법:BrowserMatchNoCase regex [!]env-variable[=value] + [[!]env-variable[=value]] ...
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_setenvif
지원:아파치 1.2 이상 (아파치 1.2에서 이 지시어는 현재 + 없어진 mod_browser 모듈에 있었다)
+ +

BrowserMatchNoCase 지시어는 BrowserMatch 지시어와 + 의미상 같다. 그러나 이 지시어는 대소문자를 구별하지않는다. + 예를 들어:

+

+ BrowserMatchNoCase mac platform=macintosh
+ BrowserMatchNoCase win platform=windows
+

+ +

BrowserMatch와 + BrowserMatchNoCase 지시어는 + SetEnvIf와 + SetEnvIfNoCase + 지시어의 특별한 경우다. 다음 주 줄은 같다:

+

+ BrowserMatchNoCase Robot is_a_robot
+ SetEnvIfNoCase User-Agent Robot is_a_robot
+

+ +
+
top
+

SetEnvIf 지시어

+ + + + + + + +
설명:요청의 성질에 따라 환경변수를 설정한다
문법:SetEnvIf attribute + regex [!]env-variable[=value] + [[!]env-variable[=value]] ...
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_setenvif
+

SetEnvIf 지시어는 요청의 성질에 + 따라 환경변수를 정의한다. 첫번째 아규먼트 attribute는 + 다음 세가지중 하나다:

+ +
    +
  1. HTTP 요청 헤더 (더 자세한 정보는 RFC2616 + 참고); 예를 들어: Host, User-Agent, + Referer, Accept-Language. 정규표현식을 + 사용하여 여러 요청 헤더를 지칭할 수 있다.
    2. + +
  2. 요청의 다음 성질중 하나: +
      +
    • Remote_Host - (있다면) 요청하는 클라이언트의 + 호스트명
      • + +
    • Remote_Addr - 요청하는 클라이언트의 IP 주소
      • + +
    • Server_Addr - 요청을 받는 서버의 IP 주소 + (2.0.43 버전 이후에만)
      • + +
    • Request_Method - 사용한 메써드 이름 + (GET, POST, 등등)
      • + +
    • Request_Protocol - 요청의 프로토콜 이름과 + 버전 (예를 들어, "HTTP/0.9", "HTTP/1.1", 등.)
      • + +
    • Request_URI - HTTP 요청에서 요청한 자원 + -- 일반적으로 URL에서 질의문자열을 제외한 스킴(scheme)과 + 호스트 이후 부분
      • +
    +
    3. + +
  3. 요청과 연관된 환경변수 이름. 그래서 SetEnvIf +지시어는 이전 지시어의 결과를 검사할 수 있다. 이전에 +SetEnvIf[NoCase] 지시어로 정의한 환경변수만을 +검사할 수 있다. '이전'이란 (서버전역과 같이) 더 넓은 영역 혹은 +지시어의 현재 영역 이전을 뜻한다. 요청 성질이 아니고 정규표현식이 +아닌 attribute는 환경변수로 취급한다.
    4. +
+ +

두번째 아규먼트는 (regex) Perl 호환 정규표현식이다. +이는 POSIX.2 egrep의 정규표현식과 비슷하다. regex가 +attribute에 대응하면 나머지 아규먼트를 처리한다.

+ +

나머지 아규먼트는 설정할 변수명과 (선택적인) 설정값들이다. +다음과 같은 형식이다

+ +
    +
  1. varname, 혹은
    2. + +
  2. !varname, 혹은
    3. + +
  3. varname=value
    4. +
+ +

첫번째 형태는 값으로 "1"을 사용한다. 두번째 형태는 변수가 + 이미 정의된 경우 변수를 제거하고, 세번째는 변수의 값으로 + value를 설정한다. 아파치 2.1부터 + value에 있는 $1..$9를 + regex의 괄호친 하위표현식으로 대체한다.

+ +

예제:

+ + SetEnvIf Request_URI "\.gif$" object_is_image=gif
+ SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
+ SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
+ :
+ SetEnvIf Referer www\.mydomain\.com intra_site_referral
+ :
+ SetEnvIf object_is_image xbm XBIT_PROCESSING=1
+ :
+ SetEnvIf ^TS* ^[a-z].* HAVE_TS
+

+ +

처음 세 줄은 이미지 파일을 요청한 경우 환경변수 + object_is_image를 설정한다. 네번째 줄은 페이지를 + www.mydomain.com 웹사이트에서 참조한 경우 + intra_site_referral을 설정한다.

+ +

마지막 예는 요청에 이름에 "TS"로 시작하고 값이 [a-z] + 중 하나로 시작하는 헤더가 있는 경우 환경변수 + HAVE_TS를 설정한다.

+ +

참고

+ +
+
top
+

SetEnvIfNoCase 지시어

+ + + + + + + + +
설명:대소문자를 구별하지않고 요청의 성질에 따라 환경변수를 +설정한다
문법:SetEnvIfNoCase attribute regex + [!]env-variable[=value] + [[!]env-variable[=value]] ...
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:FileInfo
상태:Base
모듈:mod_setenvif
지원:아파치 1.3 이후
+ +

SetEnvIfNoCase는 의미상 SetEnvIf 지시어와 같지만, + 대소문자를 구별하지않고 정규표현식을 찾는다. 예를 들어:

+

+ SetEnvIfNoCase Host Apache\.Org site=apache +

+ +

이 경우 HTTP 요청 헤더 Host:가 + Apache.Org, apache.org 등을 포함하면 + site 환경변수를 "apache"로 설정한다.

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_setenvif.xml.ko b/docs/manual/mod/mod_setenvif.xml.ko index a16f6c475a..f95ec81aa4 100644 --- a/docs/manual/mod/mod_setenvif.xml.ko +++ b/docs/manual/mod/mod_setenvif.xml.ko @@ -1,7 +1,7 @@ - + +mod_so - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_so

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:시작할때 혹은 재시작할때 실행가능한 코드와 모듈을 +서버로 읽어들인다
상태:Extension
모듈명:so_module
소스파일:mod_so.c
지원:윈도우즈에서 (항상 포함하는) Base 모듈이다.
+

요약

+ + +

몇몇 운영체제에서 아파치는 동적공유객체 + (DSO) 기술을 사용하여 서버를 다시 컴파일하지 않고도 실행중에 + 모듈을 읽어들일 수 있다.

+ +

읽어들일 코드는, 유닉스에서는 (.so 확장자를 + 가진) 일반적인 공유객체파일이고, 윈도우즈에서는 .so + 혹은 .dll 확장자를 가진다.

+ +

경고

+

아파치 1.3 모듈을 아파치 2.0에서 사용할 수 없다. + 아파치 2.0이 동적으로 읽어들이거나 아파치와 같이 컴파일하려면 + 모듈을 수정해야 한다.

+
+
+

지시어들

+ +

주제

+
+
top
+
+

윈도우즈에서 읽어들일 모듈 만들기

+ +

주의

+

윈도우즈의 모듈명 형식은 아파치 1.3.15와 2.0에서 변경되었다. + 모듈명은 이제 mod_foo.so식이다.

+ +

mod_so는 아직도 ApacheModuleFoo.dll 식의 모듈을 읽어들일 + 수 있지만, 새로운 이름 규칙을 선호한다. 모듈을 2.0에 맞게 + 수정한다면 이름을 2.0 규칙에 알맞게 고치길 바란다.

+ +

아파치 모듈 API는 유닉스 버전이거나 윈도우즈 버전이거나 + 같다. 몇몇 API는 윈도우즈에 없는 유닉스 구조에 의존하기때문에 + 사용할 수 없지만, 유닉스에서 실행되는 많은 모듈을 수정없이 + 혹은 조금 수정하여 윈도우즈에서 사용할 수 있다.

+ +

모듈은 두가지 방법으로 서버에 추가할 수 있다. 유닉스에서는 + 모듈을 서버와 같이 컴파일할 수 있다. 윈도우즈용 아파치는 + 유닉스와 달리 Configure 프로그램이 없기때문에 + 모듈의 소스파일을 ApacheCore 프로젝트 파일에 추가하고, 심볼을 + os\win32\modules.c 파일에 추가해야 한다.

+ +

두번째 방법은 모듈을 서버가 + LoadModule 지시어를 + 사용하여 시작할때 읽어들일 수 있는 공유라이브러리 DLL로 + 만드는 것이다. 이 모듈 DLL을 배포하면 서버를 재컴파일하지 + 않고 어떤 윈도우즈용 아파치에서도 모듈을 사용할 수 있다.

+ +

모듈 DLL을 만들기위해서는 모듈의 소스파일을 조금 수정해야 + 한다. DLL은 module record를 export해야 한다. (아래 참고) + 이를 위해 모듈의 module record 정의에 (아파치 헤더파일에 + 정의된) AP_MODULE_DECLARE_DATA를 추가한다. + 예를 들어, 다음과 같은 모듈이 있다면:

+ +

+ module foo_module; +

+ +

다음과 같이 수정한다:

+

+ module AP_MODULE_DECLARE_DATA foo_module; +

+ +

이 부분은 윈도우즈에서만 사용하기때문에 변경하여도 유닉스에서 + 소스를 그대로 사용할 수 있다. 또, .DEF 파일에 + 익숙하다면 대신 이 파일을 사용하여 module record를 export할 + 수도 있다.

+ +

이제 모듈을 포함한 DLL을 만든다. 이를 공유라이브러리 + libhttpd.dll을 컴파일할때 만든 libhttpd.lib export 라이브러리와 + 링크한다. 아파치 헤더파일을 올바로 찾도록 컴파일러 설정을 + 수정해야 할지도 모른다. 서버의 modules 디렉토리에서 이 + 라이브러리를 찾을 수 있다. 컴파일환경을 올바로 설정하기위해 + 기존 모듈의 .dsp 파일을 가져다 쓰거나 직접 만든 .dsp와 + 컴파일러/링커 옵션을 비교하는 것이 좋다.

+ +

이제 모듈을 DLL로 만든다. 이것을 서버의 + modules 디렉토리에 두고, + LoadModule 지시어를 사용하여 읽어들인다.

+ +
+
top
+

LoadFile 지시어

+ + + + + + +
설명:지정한 목적파일이나 라이브러리를 읽어들인다
문법:LoadFile filename [filename] ...
사용장소:주서버설정
상태:Extension
모듈:mod_so
+ +

LoadFile 지시어는 서버가 시작하거나 재시작할때 지정한 + 목적파일이나 라이브러리를 읽어들인다(link in). 이 지시어는 + 어떤 모듈이 동작하기위해 필요한 코드를 추가로 읽어들일때 + 사용한다. Filename은 절대경로이거나 ServerRoot에 대한 상대경로이다.

+ +

예를 들어:

+ +

LoadFile libexec/libxmlparse.so

+ + +
+
top
+

LoadModule 지시어

+ + + + + + +
설명:목적파일이나 라이브러리를 읽어들이고, 사용가능한 +모듈 목록에 추가한다
문법:LoadModule module filename
사용장소:주서버설정
상태:Extension
모듈:mod_so
+

LoadModule 지시어는 목적파일 혹은 라이브러리 filename을 + 읽어들이고, 사용가능한 모듈 목록에 module이라는 + 모듈 구조체를 추가한다. Module은 파일의 + module 자료형 외부변수명이며, 모듈 문서의 모듈명에 + 나온다. 예를 들면:

+ +

+ LoadModule status_module modules/mod_status.so +

+ +

ServerRoot의 modules 하위디렉토리에서 지정한 모듈을 읽어들인다.

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_so.xml.ko b/docs/manual/mod/mod_so.xml.ko index ed47c2c1ad..32676cc9f2 100644 --- a/docs/manual/mod/mod_so.xml.ko +++ b/docs/manual/mod/mod_so.xml.ko @@ -1,7 +1,7 @@ - + +mod_speling - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_speling

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:사용자가 대소문자를 잘못 사용하거나 맞춤법이 틀리는 +것을 한번까지 허용하여 잘못된 URL을 고치려고 시도한다
상태:Extension
모듈명:speling_module
소스파일:mod_speling.c
+

요약

+ + +

종종 맞춤법이 틀리거나 대소문자를 잘못 사용하여 아파치가 + 문서 요청을 서비스할 수 없는 경우가 있다. 이 모듈은 다른 + 모든 모듈들이 포기한 요청에 해당하는 문서를 찾는다. 모듈은 + 요청한 디렉토리 안에 있는 모든 문서를 요청한 문서이름과 + 대소문자 구별없이 (문자 첨가 / 생략 / 교체 + 혹은 잘못된 문자 ) 맞춤법이 한번까지 틀려도 + 봐주며 비교한다. 이런 방법으로 문서목록을 만든다.

+ +

디렉토리를 살펴본 후에,

+ + + +
+

지시어들

+ +
+ +
top
+

CheckSpelling 지시어

+ + + + + + + + + +
설명:맞춤법 모듈을 사용한다
문법:CheckSpelling on|off
기본값:CheckSpelling Off
사용장소:주서버설정, 가상호스트, directory, .htaccess
Override 옵션:Options
상태:Extension
모듈:mod_speling
지원:아파치 1.1은 CheckSpelling을 별도로 제공하였지만, +대소문자가 다른 경우만을 처리할 수 있었다. 아파치 1.3에서 아파치 +배포본의 일부가 되었다. 아파치 1.3.2 이전에는 +CheckSpelling 지시어를 "주서버"와 "가상호스트" +사용장소에서만 사용할 수 있었다.
+

이 지시어는 맞춤법 모듈의 사용여부를 결정한다. 사용한다면 + 다음을 주의하라

+ + + + +

DAV를 사용하는 디렉토리에 + mod_speling을 사용하면 안된다. 이유는 새로 업로드하려는 + doc43.html 문서를 엉뚱하게 기존의 + doc34.html 파일로 리다이렉트하는 등, DAV가 + 새로 만드는 리소스명을 기존의 파일명으로 "맞춤법 교정"을 + 시도하기 때문이다. +

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_speling.xml.ko b/docs/manual/mod/mod_speling.xml.ko index 07893cef0a..1b17392c81 100644 --- a/docs/manual/mod/mod_speling.xml.ko +++ b/docs/manual/mod/mod_speling.xml.ko @@ -1,7 +1,7 @@ - + +mod_status - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_status

+
+

가능한 언어:  en  | + ko 

+
+ + + +
설명:서버 활동과 성능에 대한 정보를 제공한다
상태:Base
모듈명:status_module
소스파일:mod_status.c
+

요약

+ +

Status 모듈은 서버 관리자에게 서버의 상태를 보여준다. + 쉽게 읽을 수 있는 HTML 페이지로 현재 서버통계를 보여준다. + 필요하다면 (표준을 따르는 브라우저에서) 페이지를 자동으로 + 갱신할 수 있다. 현재 서버 상태를 컴퓨터가 읽을 수 있는 + 간단한 목록으로 보여줄 수도 있다.

+ +

알려주는 정보는:

+ + + +

표준 아파치에는 "(*)"로 표시한 통계를 얻을 수 없다. + 이 정보를 보려면 컴파일시 옵션을 사용해야 한다.

+
+

지시어들

+ +

주제

+
+
top
+
+

Status 사용하기

+ + +

foo.com 도메인에서 접근한 브라우저에게만 상태를 보여주려면 + httpd.conf 설정파일에 다음과 같이 추가한다

+

+ <Location /server-status>
+ SetHandler server-status
+
+ Order Deny,Allow
+ Deny from all
+ Allow from .foo.com
+ </Location> +

+ +

이제 웹브라우저로 + http://your.server.name/server-status 페이지에 + 접근하면 서버 통계를 볼 수 있다.

+
top
+
+

자동 갱신

+ + +

브라우저가 "재갱신"을 지원한다면 status 페이지를 자동으로 + 갱신할 수 있다. N 초마다 갱신하려면 + http://your.server.name/server-status?refresh=N + 페이지를 사용하라.

+ +
top
+
+

컴퓨터가 읽을 수 있는 Status 파일

+ + +

http://your.server.name/server-status?auto에서 + 컴퓨터가 쉽게 읽을 수 있는 status 파일을 얻을 수 있다. 이 + 형식은 아파치 /support 디렉토리에 있는 + log_server_status Perl 프로그램과 같이 자동으로 + 실행하는 프로그램에 유용하다.

+ +
+ mod_status를 서버와 같이 + 컴파일하였다면 디렉토리별 설정파일을 (예를 + 들어, .htaccess) 포함하여 모든 + 설정파일에서 핸들러를 사용할 수 있다. 그래서 사이트에 + 보안 문제가 발생할 수 있다. +
+ +
+
top
+

ExtendedStatus 지시어

+ + + + + + + + +
설명:각 요청에 대한 자세한 상태 정보를 기록한다
문법:ExtendedStatus On|Off
기본값:ExtendedStatus Off
사용장소:주서버설정
상태:Base
모듈:mod_status
지원:ExtendedStatus는 아파치 1.3.2 이후에만 있다.
+

이 설정은 서버 전체에 적용되며, 가상호스트별로 키고 끌 + 수 없다. 자세한 상태 정보를 모으면 서버가 느려질 수 있다.

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_status.xml.ko b/docs/manual/mod/mod_status.xml.ko index 2307cc0641..2a79c02f83 100644 --- a/docs/manual/mod/mod_status.xml.ko +++ b/docs/manual/mod/mod_status.xml.ko @@ -1,7 +1,7 @@ - + +mod_suexec - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_suexec

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + + +
설명:CGI 스크립트를 특정 사용자와 그룹 권한으로 실행한다
상태:Extension
모듈명:suexec_module
소스파일:mod_suexec.c
지원:Available in Apache 2.0 and later
+

요약

+ +

이 모듈은 suexec 지원 + 프로그램을 사용하여 CGI 스크립트를 특정 사용자와 그룹 + 권한으로 실행한다.

+
+

지시어들

+ +

참고

+
+ +
top
+

SuexecUserGroup 지시어

+ + + + + + + +
설명:CGI 프로그램이 사용할 사용자와 그룹 권한
문법:SuexecUserGroup User Group
사용장소:주서버설정, 가상호스트
상태:Extension
모듈:mod_suexec
지원:SuexecUserGroup은 2.0 이후에만 있다.
+

SuexecUserGroup 지시어는 CGI 프로그램이 + 사용할 사용자와 그룹을 설정한다. CGI가 아닌 요청은 계속 + User 지시어로 지정한 사용자가 처리한다. 이 지시어는 아파치 + 1.3에서 VirtualHost 안에 사용한 User와 Group 지시어를 + 대체한다.

+ +

예제

+ + SuexecUserGroup nobody nogroup +

+ + +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_suexec.xml.ko b/docs/manual/mod/mod_suexec.xml.ko index 1baf452226..3bf359c32b 100644 --- a/docs/manual/mod/mod_suexec.xml.ko +++ b/docs/manual/mod/mod_suexec.xml.ko @@ -1,7 +1,7 @@ - + +mod_unique_id - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_unique_id

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:각 요청마다 유일한 식별자를 가지는 환경변수를 +제공한다
상태:Extension
모듈명:unique_id_module
소스파일:mod_unique_id.c
+

요약

+ + +

이 모듈은 어떤 특별한 상황에서도 "모든" 요청중에서 + 유일하도록 보장된 식별자(identifier)를 모든 요청에 제공한다. + 심지어 이 식별자는 특별하게 구성한 클러스터의 여러 컴퓨터들 + 중에서도 유일하다. 각 요청마다 환경변수 + UNIQUE_ID를 설정한다. 유일한 식별자는 여러가지 + 용도로 사용할 수 있지만, 설명은 이 문서의 범위를 넘어선다.

+
+

지시어들

+

이 모듈에는 지시어가 없습니다.

+

주제

+
+
top
+
+

이론

+ + +

먼저 유닉스 시스템에서 아파치 서버가 어떻게 동작하는지 + 간략히 살펴보자. Windows NT는 현재 이 기능을 지원하지 않는다. + 유닉스에서 아파치는 여러 자식을 만들고, 자식 프로세스는 + 한번에 한 요청씩 처리한다. 자식은 실행중에 여러 요청을 + 처리한다. 여기서 중요한 것은 자식들이 서로 자료를 + 공유하지 않는다는 점이다. 앞으로 자식을 httpd 프로세스라고 + 한다.

+ +

여러 컴퓨터로 웹사이트를 서비스한다면 클러스터(cluster)라고 + 부른다. 각 컴퓨터는 여러 아파치를 실행할 수 있다. 이들 모두를 + "우주"로 보면, 클러스터에 있는 컴퓨터들간에 많은 통신없이 + 각 요청마다 우주에서 유일한 식별자를 만들 수 있다.

+ +

클러스터에 있는 컴퓨터는 다음 요구사항을 만족해야 한다. + (컴퓨터를 한대만 사용하더라도 컴퓨터 시간을 NTP와 동기해야 + 한다.)

+ + + +

운영체제에서 pid (프로세스 id)가 32비트에 들어간다고 + 가정한다. 운영체제가 pid로 32비트 이상을 사용한다면 간단하지만 + 코드를 수정해야 한다.

+ +

이런 가정하에 우리는 어떤 시점에서 클러스터의 어떤 컴퓨터에 + 있는 어떤 httpd 프로세스를 다른 모든 httpd 프로세스들과 + 구별할 수 있다. 컴퓨터의 IP 주소와 httpd 프로세스의 pid만으로도 + 충분히 구별할 수 있다. 그래서 요청에 대해 유일한 구별자를 + 만드려면 시간차를 구별할 수만 있으면 된다.

+ +

시간을 구별하기위해 유닉스 시간(timestamp, 세계 표준시로 + 1970년 1월 1일 이후 지난 초)과 16비트 카운터를 사용한다. + 유닉스 시간은 초단위이고, 카운터는 일 초동안 65536까지 + 증가한다. ( ip_addr, pid, time_stamp, counter ) + 묶음은 어떤 httpd 프로세스에서 일 초동안 65536 요청을 구별할 + 수 있다. 그러나 카운터는 pid를 재사용하는 문제를 해결해야 + 한다.

+ +

httpd 자식을 만들면 카운터는 ( 현재 밀리초 나누기 10 )을 + 65536으로 나눈 나머지가 된다. (몇몇 시스템의 밀리초 시간에서 + 하위 비트가 일치하지않는 문제때문에 이 공식을 만들었다.) + 유일한 식별자를 만들때 사용하는 시간은 웹서버가 요청을 받은 + 시간이다. 카운터는 식별자를 만들때마다 증가한다 (그리고 + 다시 시작한다).

+ +

커널은 프로세스를 포크할때(fork) 각 프로세스에 pid를 + 할당하고, pid는 다시 시작할 수 있다. (pid는 많은 유닉스에서 + 16비트이지만, 최근 시스템은 32비트로 확장했다.) 그래서 시간이 + 지나면 같은 pid를 재사용할 수 있다. 그러나 같은 시간에 pid를 + 재사용하지 않는다면 위의 묶음은 유일하다. 즉, 우리는 시스템이 + 일초동안 프로세스를 65536개 이상 만들지 않는다고 가정한다. + (어떤 유닉스에서는 32768개 이상 프로세스를 만들면 pid 재사용 + 문제가 발생할 수 있지만, 이것조차도 일어날 것같지 않다.)

+ +

시간이 어떤 이유에서건 반복된다고 가정해보자. 즉, 시스템 + 시계가 꼬여서 시간이 과거로 돌아가는 (혹은 시계가 너무 앞서가서 + 올바로 재설정한후 미래에 같은 시간이 되는) 경우다. 이 경우 + pid와 시간을 모두 재사용할 수 있다. 카운터의 초기화 공식은 + 이 문제를 해결하려고 고안되었다. 우리는 실제 무작위 숫자로 + 카운터를 초기화하길 원하지만, 많은 시스템에서 이런 수를 + 쉽게 얻을 수 없다. (예를 들어, seed가 필요하기때문에 + rand()를 사용할 수 없고, 시간은 최소한 일초 단위이기때문에 + 시간으로 seed로 사용할 수 없다.) 즉 완벽한 해결책이 없다.

+ +

그럼 이 방법은 얼마나 괜찮을까? 컴퓨터중 하나가 요청을 + 초당 최대 500개 (시스템은 일반적으로 정적인 파일을 전송하는 + 것 이상의 작업을 하므로 이 글을 쓰는 시점에서 상당히 높은 + 값이다.) 서비스한다고 가정하자. 동시에 얼마만큼의 클라이언트를 + 처리하는가에 따라 자식의 개수가 결정된다. 그러나 우리는 + 비관적으로 한 자식이 요청을 초당 500개 처리할 수 있다고 + 가정한다. 재사용한 pid를 가진 자식의 500개 요청과 이전 자식의 + 500개 요청의 카운터값이 겹칠 수 있는 카운터 시작값 경우수는 + 1000개이다. 그래서 (초단위에서) 자식이 카운터값을 반복하여 + 유일성이 깨질 확률은 1.5%이다. 이것은 매우 비관적인 가정이며, + 실제 이럴 경우는 상당히 더 낮다. 그래도 시스템에서 이런 + 일이 발생할 것 같다면 (소스를 수정하여) 카운터를 32비트로 + 만들어라.

+ +

섬머타임때문에 시계가 "뒤로 가는" 것을 걱정할지도 모른다. + 그러나 여기서 사용하는 시간은 국제 표준시(UTC), 즉 시간이 + "항상" 앞으로 가므로 문제가 없다. x86기반 유닉스에서는 + 적절한 설정이 필요하다. 메인보드 시계가 UTC를 사용하도록 + 설정해야 한다. 그러나 NTP를 사용한다면 재시작후 조금 지나면 + UTC 시간에 올바로 맞춘다.

+ +

환경변수 UNIQUE_ID는 MIME base64 인코딩과 + 비슷한 방법으로 112비트 (32비트 IP 주소, 32비트 pid, 32비트 + 시간, 16비트 카운터) 묶음을 알파벳 [A-Za-z0-9@-]로 + 표현한다. 실제 MIME base64 알파벳은 + [A-Za-z0-9+/]이지만 +와 + /는 URL에서 특별한 의미로 사용하므로 제외했다. + 모든 값을 네트웍 바이트순서로 인코딩하기때문에 다른 바이트순서를 + 사용하는 아키텍쳐간에 값이 같다. 실제 인코딩 순서는 + 시간, IP 주소, pid, 카운터 순서이다. 이 순서에는 어떤 목적이 + 있지만, 프로그램은 인코딩 순서에 의존하여 값들을 분석하면 + 안됨을 강조한다. 프로그램은 인코딩된 UNIQUE_ID + 전체를 한 단위로 생각하고, 다른 UNIQUE_ID와 + 동일한지만 비교할 수 있다.

+ +

순서는 앞으로 기존의 UNIQUE_ID 데이터베이스와 + 충돌을 염려하지않고 인코딩을 변경할 수 있도록 고안했다. + 새로운 인코딩은 첫 항목으로 시간을 사용하거나, 같은 알파벳과 + 비트 길이를 사용할 수도 있다. 시간이 기본적으로 증가하는 값이므로 + 클러스터에 있는 모든 컴퓨터가 요청 서비스를 중단하고 이전 + 인코딩 형식을 그만 사용하기위해 기준 초(flag second)만으로 + 충분하다. 이후 요청을 재게하고 새로운 인코딩을 시작할 수 + 있다.

+ +

우리는 이 방법이 이 문제에 대하여 상대적으로 포팅가능한 + 해결책이라고 믿는다. 이 방법은 Windows NT와 같은 멀티쓰레드 + 시스템으로 확장할 수 있고, 앞으로 용도에 따라 확장할 수 + 있다. 미래에 필요한만큼 더 긴 식별자를 만들 수 있기때문에 + 생성한 식별자는 기본적으로 영원한 수명을 가진다. 기본적으로 + 클러스터의 컴퓨터들 사이에 통신이 필요없고 (부하가 작은 + NTP 동기만 필요하다), httpd 프로세스 사이에 통신도 필요없다 + (커널이 부여하는 pid값이 암묵적인 통신이다). 매우 특이한 + 상황이라면 인식자 크기를 줄일 수 있지만 더 많은 정보를 + 가정해야 한다. (예를 들어, 어떤 사이트에서 32비트 IP 주소 + 구분은 불필요하게 크지만, 이를 줄이는 방법은 상황에 따라 + 다르다.)

+
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_unique_id.xml.ko b/docs/manual/mod/mod_unique_id.xml.ko index d5fc6868b2..8808e8ea4d 100644 --- a/docs/manual/mod/mod_unique_id.xml.ko +++ b/docs/manual/mod/mod_unique_id.xml.ko @@ -1,7 +1,7 @@ - + +mod_userdir - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+
+

아파치 모듈 mod_userdir

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ + + +
설명:사용자별 디렉토리
상태:Base
모듈명:userdir_module
소스파일:mod_userdir.c
+

요약

+ +

이 모듈을 사용하면 http://example.com/~user/ 식으로 +사용자별 디렉토리에 접근할 수 있다.

+
+

지시어들

+ +

참고

+
+ +
top
+

UserDir 지시어

+ + + + + + + +
설명:사용자별 디렉토리 위치
문법:UserDir directory-filename
기본값:UserDir public_html
사용장소:주서버설정, 가상호스트
상태:Base
모듈:mod_userdir
+ +

UserDir 지시어는 사용자의 문서에 대한 +요청을 받을때 사용자 홈디렉토리 안에서 사용할 실제 디렉토리를 +지정한다. Directory-filename은 다음 중 하나이다:

+ + + +

Userdir 지시어에 enabled나 +disabled 키워드를 사용하지 않으면, 아규먼트를 +파일명 패턴으로 처리하여 디렉토리로 변환한다. +http://www.foo.com/~bob/one/two.html에 대한 요청은 +다음과 같이 변환된다:

+ + + + + + + +
사용한 UserDir 지시어변환한 경로
UserDir public_html~bob/public_html/one/two.html
UserDir /usr/web/usr/web/bob/one/two.html
UserDir /home/*/www/home/bob/www/one/two.html
+ +

다음 지시어는 클라이언트에게 리다이렉션을 보낸다:

+ + + + + + + +
사용한 UserDir 지시어변환한 경로
UserDir http://www.foo.com/usershttp://www.foo.com/users/bob/one/two.html
UserDir +http://www.foo.com/*/usrhttp://www.foo.com/bob/usr/one/two.html
UserDir +http://www.foo.com/~*/http://www.foo.com/~bob/one/two.html
+ +
+ 이 지시어를 사용할때 주의하라; 예를 들어, +"UserDir ./"는 "/~root"를 아마도 바람직하지 않게 +"/"로 변환한다. 설정에 "UserDir + disabled root"를 포함하길 강력히 권한다. 자세한 정보를 알려면 +Directory 지시어와 보안 팁도 참고하라. +
+ +

추가 예제:

+ +

몇몇 사용자에게만 UserDir 디렉토리를 허용한다면, +다음과 같다:

+ +

+UserDir disabled
+UserDir enabled user1 user2 user3 +

+ +

대부분의 사용자에게 UserDir 디렉토리를 허용하고 +일부만 거부한다면, 다음과 같다:

+ +

+UserDir enabled
+UserDir disabled user4 user5 user6 +

+ +

다른 사용자 디렉토리를 지정할 수도 있다. +다음과 같은 명령어를 사용한다면:

+

+Userdir public_html /usr/web http://www.foo.com/ +

+

http://www.foo.com/~bob/one/two.html 요청을 하면, +먼저 ~bob/public_html/one/two.html 페이지를 찾고, +/usr/web/bob/one/two.html을 찾은 후, 마지막으로 +http://www.foo.com/bob/one/two.html으로 리다이렉션을 보낸다.

+

리다이렉션을 사용한다면 목록의 마지막에 두어야 한다. +아파치는 리다이렉션이 성공했는지 알 수 없기때문에, 리다이렉션을 +목록 앞에 두면 항상 리다이렉션을 사용하게 된다.

+ + +

참고

+ +
+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_userdir.xml.ko b/docs/manual/mod/mod_userdir.xml.ko index 1f2640c861..0fb0d26e9e 100644 --- a/docs/manual/mod/mod_userdir.xml.ko +++ b/docs/manual/mod/mod_userdir.xml.ko @@ -1,7 +1,7 @@ - + +모듈을 설명하기위해 사용한 용어들 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1

모듈을 설명하기위해 사용한 용어들

+
+

가능한 언어:  en  | + ja  | + ko 

+
+ +

이 문서는 아파치 모듈을 설명하기위해 + 사용한 용어를 설명한다.

+
+
+
top
+
+

설명

+ +

모듈 목적에 대한 간단한 설명.

+
top
+
+

상태

+ +

모듈이 아파치 웹서버와 얼마나 밀접히 연관되있는지 나타낸다. + 즉, 특정 모듈과 모듈의 기능을 사용하기위해서 서버를 다시 + 컴파일해야 할 경우가 있다. 이 속성의 값은:

+ +
+
MPM
+ +
상태가 "MPM"인 모듈은 다중처리 + 모듈이다. 다른 종류의 모듈과 달리 아파치는 오직 한 + MPM만을 사용한다. 이런 종류의 모듈은 기본적인 요청 처리와 + 분배를 담당한다.
+ +
Base
+ +
상태가 "Base"인 모듈은 기본적으로 서버와 같이 컴파일되므로, + 설정에서 모듈을 제거하지 않는 한 보통 사용할 수 있다.
+ +
Extension
+ +
상태가 "Extension"인 모듈은 보통 서버와 같이 컴파일되지 + 않는다. 모듈과 모듈의 기능을 사용하려면 서버 컴파일 + 구성파일을 변경하고 아파치를 다시 컴파일해야 한다.
+ +
Experimental
+ +
"Experimental" 상태는 모듈이 아파치 배포본에 포함되있지만, + 사용하려면 위험을 감수해야 한다. 모듈에 대한 문서가 있지만, + 모듈을 지원한다는 말은 아니다.
+ +
External
+ +
"External" 상태는 기본 아파치 배포본에 포함되지 않은 + 모듈("제삼자가 만든 모듈")이다. 우리는 이런 모듈에 책임이 + 없고 지원하지도 않는다.
+
+
top
+
+

소스파일

+ +

간단하게 말해서 모듈 소스코드가 있는 소스파일명이다. + <IfModule> + 지시어에서 사용하는 이름이기도 하다.

+
top
+
+

모듈명

+ +

모듈을 지칭하는 문자열로, 모듈을 동적으로 읽어들이는 + LoadModule 지시어에서 + 사용한다. 정확히 말하면 소스파일에서 module 형의 외부변수 + 이름이다.

+
top
+
+

지원

+ +

모듈이 원래 아파치 버전 2 배포본에 포함되지 않았다면, + 모듈을 처음 소개한 버전을 알려준다. 또, 모듈이 특정 + 플래폼용이라면 상세히 설명한다.

+
+
+

가능한 언어:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/module-dict.xml.ko b/docs/manual/mod/module-dict.xml.ko index 7190af6c71..f099e11e71 100644 --- a/docs/manual/mod/module-dict.xml.ko +++ b/docs/manual/mod/module-dict.xml.ko @@ -1,7 +1,7 @@ - + +지시어 빠른참조 - Apache HTTP Server + + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > 모듈
+

지시어 빠른참조

+
+

가능한 언어:  de  | + en  | + ja  | + ko 

+
+ +

이 문서는 아파치 설정지시어 각각의 용도, 기본값, 상태, + 사용장소를 보여준다. 이들은 지시어 사전에서 설명한다.

+ +

첫번째 열은 지시어 이름과 용도를 알려준다. 두번째 열은 + 지시어에 기본값이 있다면 기본값을 보여준다. 만약 기본값이 + 너무 길다면, "+" 기호로 생략했음을 알린다.

+ +

세번째와 네번째 열은 각각 아래 표에 따라 지시어를 사용할 + 수 있는 장소와 지시어의 상태를 나타낸다.

+
+
+ + + +
 A  |  B  |  C  |  D  |  E  |  F  |  G  |  H  |  I  |  K  |  L  |  M  |  N  |  O  |  P  |  R  |  S  |  T  |  U  |  V  |  W  |  X  + + + + + +
s주서버설정
v가상호스트
ddirectory
h.htaccess
 + + + + + + +
CCore
MMPM
BBase
EExtension
XExperimental
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AcceptMutex Default|method Default sM
Method that Apache uses to serialize multiple children +accepting requests on network sockets
AcceptPathInfo On|Off|Default Default svdhC
Resources accept trailing pathname information
AccessFileName filename [filename] ... .htaccess svC
Name of the distributed configuration file
Action action-type cgi-script [virtual]svdhB
특정 핸들러나 content-type에 대해 CGI 스크립트를 +사용한다
AddAlt string file [file] ...svdhB
파일명으로 선택한 아이콘대신 사용할 파일 설명글
AddAltByEncoding string MIME-encoding +[MIME-encoding] ...svdhB
MIME-encoding으로 선택한 아이콘대신 사용할 파일 +설명글
AddAltByType string MIME-type +[MIME-type] ...svdhB
MIME content-type으로 선택한 아이콘대신 사용할 파일 +설명글
AddCharset charset extension +[extension] ...svdhB
Maps the given filename extensions to the specified content +charset
AddDefaultCharset On|Off|charset Off svdhC
Default character set to be added for a +response without an explicit character set
AddDescription string file [file] ...svdhB
파일에 대한 설명
AddEncoding MIME-enc extension +[extension] ...svdhB
Maps the given filename extensions to the specified encoding +type
AddHandler handler-name extension +[extension] ...svdhB
Maps the filename extensions to the specified +handler
AddIcon icon name [name] +...svdhB
이름으로 선택한 파일에 사용할 아이콘
AddIconByEncoding icon MIME-encoding +[MIME-encoding] ...svdhB
MIME content-encoding으로 선택한 파일에 사용할 아이콘
AddIconByType icon MIME-type +[MIME-type] ...svdhB
MIME content-type으로 선택한 파일에 사용할 아이콘
AddInputFilter filter[;filter...] +extension [extension] ...svdhB
Maps filename extensions to the filters that will process +client requests
AddLanguage MIME-lang extension +[extension] ...svdhB
Maps the given filename extension to the specified content +language
AddModuleInfo module-name stringsvE
Adds additional information to the module +information displayed by the server-info handler
AddOutputFilter filter[;filter...] +extension [extension] ...svdhB
Maps filename extensions to the filters that will process +responses from the server
AddOutputFilterByType filter[;filter...] +MIME-type [MIME-type] ...svdhC
assigns an output filter to a particular MIME-type
AddType MIME-type extension +[extension] ...svdhB
Maps the given filename extensions onto the specified content +type
Alias URL-path +file-path|directory-pathsvB
URL을 특정 파일시스템 장소로 대응한다
AliasMatch regex +file-path|directory-pathsvB
정규표현식을 사용하여 URL을 파일시스템 장소로 +대응한다
Allow from all|host|env=env-variable +[host|env=env-variable] ...dhB
서버의 일부에 접근할 수 있는 호스트를 지정한다
AllowCONNECT port [port] ... 443 563 svE
Ports that are allowed to CONNECT through the +proxy
AllowEncodedSlashes On|Off Off svC
Determines whether encoded path separators in URLs are allowed to +be passed through
AllowOverride All|None|directive-type +[directive-type] ... All dC
Types of directives that are allowed in +.htaccess files
Anonymous user [user] ...dhE
암호검사없이 접근을 허용할 사용자 아이디들을 +지정한다
Anonymous_LogEmail On|Off On dhE
입력한 암호를 오류로그에 기록할지 여부
Anonymous_MustGiveEmail On|Off On dhE
암호가 없어도 가능한지 여부
Anonymous_NoUserID On|Off Off dhE
사용자 아이디가 없어도 가능하지 여부
Anonymous_VerifyEmail On|Off Off dhE
암호가 올바른 형식의 전자우편 주소인지 검사 +여부
AssignUserID user-id group-idvM
Tie a virtual host to a user and group ID
AuthBasicAuthoritative On|Off On dhB
인증과 권한부여를 저수준 모듈에 넘겨줄지 결정한다
AuthBasicProvider On|Off|provider-name +[provider-name] ... On dhB
이 위치에 대한 인증제공자를 지정한다
AuthDBMGroupFile file-pathdhE
인증에 사용할 사용자 그룹 목록을 저장하는 데이터베이스 +파일명을 지정한다
AuthDBMType default|SDBM|GDBM|NDBM|DB default dhE
암호를 저장하는 데이터베이스 파일 종류를 +지정한다
AuthDBMUserFile file-pathdhE
인증할 사용자와 암호 목록을 저장하는 데이터베이스 +파일명을 지정한다
AuthDefaultAuthoritative On|Off On dhB
인증을 저수준 모듈로 넘겨줄지 여부
AuthDigestAlgorithm MD5|MD5-sess MD5 dhX
digest authentication에서 challenge와 response +hash를 계산하는 알고리즘을 선택한다
AuthDigestDomain URI [URI] ...dhX
digest authentication에서 같은 보호영역에 속하는 +URI들
AuthDigestNcCheck On|Off Off sX
서버가 보내는 nonce-count를 검사할지 여부
AuthDigestNonceFormat formatdhX
nonce를 만드는 방법을 결정한다
AuthDigestNonceLifetime seconds 300 dhX
서버 nonce가 유효한 기간
AuthDigestProvider On|Off|provider-name +[provider-name] ... On dhX
이 위치에 대한 인증제공자를 지정한다
AuthDigestQop none|auth|auth-int [auth|auth-int] auth dhX
digest authentication가 사용할 +보호수준(quality-of-protection)을 지정한다.
AuthDigestShmemSize size 1000 sX
클라이언트를 추적하기위해 할당하는 공유메모리량
AuthGroupFile file-pathdhB
인증에 사용할 사용자 그룹 목록을 저장하는 문자파일명을 +지정한다
AuthLDAPAuthoritative on|off on dhX
Prevent other authentication modules from +authenticating the user if this one fails
AuthLDAPBindDN distinguished-namedhX
Optional DN to use in binding to the LDAP server
AuthLDAPBindPassword passworddhX
Password used in conjuction with the bind DN
AuthLDAPCharsetConfig file-pathsX
Language to charset conversion configuration file
AuthLDAPCompareDNOnServer on|off on dhX
Use the LDAP server to compare the DNs
AuthLDAPDereferenceAliases never|searching|finding|always Always dhX
When will the module de-reference aliases
AuthLDAPEnabled on|off on dhX
Turn on or off LDAP authentication
AuthLDAPFrontPageHack on|off off dhX
Allow LDAP authentication to work with MS FrontPage
AuthLDAPGroupAttribute attributedhX
LDAP attributes used to check for group membership
AuthLDAPGroupAttributeIsDN on|off on dhX
Use the DN of the client username when checking for +group membership
AuthLDAPRemoteUserIsDN on|off off dhX
Use the DN of the client username to set the REMOTE_USER +environment variable
AuthLDAPUrl urldhX
URL specifying the LDAP search parameters
AuthName auth-domaindhC
Authorization realm for use in HTTP +authentication
AuthType Basic|DigestdhC
Type of user authentication
AuthUserFile file-pathdhB
인증할 사용자명와 암호 목록을 저장하는 문자파일명을 +지정한다
AuthzDBMAuthoritative On|Off On dhE
권한부여를 저수준 모듈로 넘겨줄지 여부
AuthzDBMType default|SDBM|GDBM|NDBM|DB default dhE
암호를 저장하는 데이터베이스 파일 종류를 지정한다
AuthzDefaultAuthoritative On|Off On dhB
권한부여를 저수준 모듈로 넘겨줄지 여부
AuthzGroupFileAuthoritative On|Off On dhB
권한부여를 저수준 모듈로 넘겨줄지 여부
AuthzOwnerAuthoritative On|Off On dhE
권한부여를 저수준 모듈로 넘겨줄지 여부
AuthzUserAuthoritative On|Off On dhB
권한부여를 저수준 모듈로 넘겨줄지 여부
BrowserMatch regex [!]env-variable[=value] +[[!]env-variable[=value]] ...svdhB
HTTP User-Agent에 따라 환경변수를 설정한다
BrowserMatchNoCase regex [!]env-variable[=value] + [[!]env-variable[=value]] ...svdhB
대소문자를 구별하지않고 User-Agent에 따라 환경변수를 +설정한다
CacheDefaultExpire seconds 3600 (one hour) svX
만기시간을 지정하지않은 문서를 캐쉬할 기본 기간.
CacheDirLength length 2 svX
하위디렉토리명의 문자개수
CacheDirLevels levels 3 svX
캐쉬의 하위디렉토리 깊이.
CacheDisable url-stringsvX
특정 URL을 캐쉬하지 않는다
CacheEnable cache_type url-stringsvX
지정한 저장관리자를 사용하여 지정한 URL을 캐쉬한다
CacheExpiryCheck On|Off On svX
캐쉬에서 파일을 찾을때 만기시간을 고려할지 여부
CacheFile file-path [file-path] ...sX
Cache a list of file handles at startup time
CacheForceCompletion Percentage 60 svX
요청이 취소되더라도 서버가 파일을 계속 캐쉬하기위해 +필요한 문서의 서비스률.
CacheGcClean hours url-string ? svX
URL에 해당하는 변하지않은 캐쉬파일을 유지할 시간
CacheGcDaily time ? svX
매일 가비지컬랙터를 실행할 반복 시간 (24시 시계)
CacheGcInterval hourssvX
가비지컬랙터를 실행하는 간격.
CacheGcMemUsage KBytes ? svX
가비지컬랙터가 사용할 최대 메모리량 (kilobyte 단위)
CacheGcUnused hours url-string ? svX
URL에 해당하는 참조되지않은 캐쉬파일을 유지할 기간.
CacheIgnoreCacheControl On|Off Off svX
클라이언트가 캐쉬하지않는 내용을 요청함을 무시한다.
CacheIgnoreNoLastMod On|Off Off svX
응답에 Last Modified 헤더가 없다는 사실을 무시한다.
CacheLastModifiedFactor float 0.1 svX
LastModified 시간으로 만기시간을 계산하는데 사용하는 +계수.
CacheMaxExpire seconds 86400 (하루) svX
문서를 캐쉬하는 초단위 최대시간
CacheMaxFileSize bytes 1000000 svX
캐쉬에 저장할 문서의 최대크기 (바이트 단위)
CacheMinFileSize bytes 1 svX
캐쉬에 저장할 문서의 최소크기 (바이트 단위)
CacheNegotiatedDocs On|Off Off svB
Allows content-negotiated documents to be +cached by proxy servers
CacheRoot directorysvX
캐쉬 파일을 저장할 디렉토리 root
CacheSize KBytes 1000000 svX
캐쉬로 사용할 최대 디스크공간 (KByte 단위)
CacheTimeMargin ? ? svX
문서를 캐쉬할 최소시간 한계
CGIMapExtension cgi-path .extensiondhC
Technique for locating the interpreter for CGI +scripts
CharsetDefault charsetsvdhX
변환할 문자집합
CharsetOptions option [option] ... DebugLevel=0 NoImpl +svdhX
문자집합 변환 기능을 설정
CharsetSourceEnc charsetsvdhX
파일 원본의 문자집합
CheckSpelling on|off Off svdhE
맞춤법 모듈을 사용한다
ChildPerUserID user-id group-id +num-childrensM
Specify user ID and group ID for a number of child +processes
ContentDigest On|Off Off svdhC
Enables the generation of Content-MD5 HTTP Response +headers
CookieDomain domainsvdhE
The domain to which the tracking cookie applies
CookieExpires expiry-periodsvdhE
Expiry time for the tracking cookie
CookieLog filenamesvB
Sets filename for the logging of cookies
CookieName token Apache svdhE
Name of the tracking cookie
CookieStyle + Netscape|Cookie|Cookie2|RFC2109|RFC2965 Netscape svdhE
Format of the cookie header field
CookieTracking on|off off svdhE
Enables tracking cookie
CoreDumpDirectory directorysM
Directory where Apache attempts to +switch before dumping core
CustomLog file|pipe +format|nickname +[env=[!]environment-variable]svB
Sets filename and format of log file
Dav On|Off|provider-name Off dE
WebDAV HTTP 메써드를 시작한다
DavDepthInfinity on|off off svdE
PROPFIND의 Depth: Infinity 요청을 허가한다
DavLockDB file-pathsvE
DAV 잠금 데이터베이스 위치
DavMinTimeout seconds 0 svdE
서버가 DAV 자원에 대해 유지할 잠금의 최소시간
DefaultIcon url-pathsvdhB
특정 아이콘을 설정하지않은 파일에 사용할 아이콘
DefaultLanguage MIME-langsvdhB
Sets all files in the given scope to the specified +language
DefaultType MIME-type text/plain svdhC
MIME content-type that will be sent if the +server cannot determine a type in any other way
DeflateBufferSize value 8096 svE
zlib이 한번에 압축할 크기
DeflateCompressionLevel valuesvE
출력을 어느정도 압축하는가
DeflateFilterNote [type] notenamesvE
압축률을 로그에 기록한다
DeflateMemLevel value 9 svE
zlib이 압축할때 사용하는 메모리량
DeflateWindowSize value 15 svE
Zlib 압축 window size
Deny from all|host|env=env-variable +[host|env=env-variable] ...dhB
서버 접근을 거부할 호스트를 지정한다
<Directory directory-path> +... </Directory>svC
Enclose a group of directives that apply only to the +named file-system directory and sub-directories
DirectoryIndex + local-url [local-url] ... index.html svdhB
클라이언트가 디렉토리를 요청할때 찾아볼 자원 목록
<DirectoryMatch regex> +... </DirectoryMatch>svC
Enclose directives that apply to +file-system directories matching a regular expression and their +subdirectories
DocumentRoot directory-path /usr/local/apache/h +svC
Directory that forms the main document tree visible +from the web
EnableExceptionHook On|Off Off sM
Enables a hook that runs exception handlers +after a crash
EnableMMAP On|Off On svdhC
Use memory-mapping to read files during delivery
EnableSendfile On|Off On svdhC
Use the kernel sendfile support to deliver files to the client
ErrorDocument error-code documentsvdhC
What the server will return to the client +in case of an error
ErrorHeader set|append|add|unset|echo header +[value] [env=[!]variable]svdhE
Configure HTTP response headers also for error responses
ErrorLog file-path|syslog[:facility] logs/error_log (Uni +svC
Location where the server will log errors
ExamplesvdhX
아파치 모듈 API를 설명하기위한 예제 지시어
ExpiresActive On|OffsvdhE
Expires 헤더를 생성한다
ExpiresByType MIME-type +<code>secondssvdhE
MIME type으로 Expires 헤더값을 설정한다
ExpiresDefault <code>secondssvdhE
만기시간을 계산하는 기본 알고리즘
ExtendedStatus On|Off Off sB
각 요청에 대한 자세한 상태 정보를 기록한다
ExtFilterDefine filtername parameterssE
외부 필터를 정의한다
ExtFilterOptions option [option] ... DebugLevel=0 NoLogS +dE
mod_ext_filter 옵션을 설정한다
FileETag component ... INode MTime Size svdhC
File attributes used to create the ETag +HTTP response header
<Files filename> ... </Files>svdhC
Contains directives that apply to matched +filenames
<FilesMatch regex> ... </FilesMatch>svdhC
Contains directives that apply to regular-expression matched +filenames
ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback] Prefer svdhB
Action to take if a single acceptable document is not +found
ForceType MIME-type|NonedhC
Forces all matching files to be served with the specified +MIME content-type
ForensicLog filename|pipesvE
Sets filename of the forensic log
Group unix-group #-1 sM
Group under which the server will answer +requests
Header set|append|add|unset|echo header +[value] [env=[!]variable]svdhE
Configure HTTP response headers
HeaderName filenamesvdhB
파일목록 위에 삽입할 파일의 이름
HostnameLookups On|Off|Double Off svdC
Enables DNS lookups on client IP addresses
IdentityCheck On|Off Off svdE
Enables logging of the RFC 1413 identity of the remote +user
IdentityCheckTimeout seconds 30 svdE
Determines the timeout duration for ident requests
<IfDefine [!]parameter-name> ... + </IfDefine>svdhC
Encloses directives that will be processed only +if a test is true at startup
<IfModule [!]module-name> ... + </IfModule>svdhC
Encloses directives that are processed conditional on the +presence or absence of a specific module
<IfVersion [[!]operator] version> ... +</IfVersion>svdhE
contains version dependent configuration
ImapBase map|referer|URL http://servername/ svdhB
Default base for imagemap files
ImapDefault error|nocontent|map|referer|URL nocontent svdhB
Default action when an imagemap is called with coordinates +that are not explicitly mapped
ImapMenu none|formatted|semiformatted|unformattedsvdhB
Action if no coordinates are given when calling +an imagemap
Include file-path|directory-pathsvdC
Includes other configuration files from within +the server configuration files
IndexIgnore file [file] ...svdhB
디렉토리 목록에서 숨길 파일목록을 추가한다
IndexOptions [+|-]option [[+|-]option] +...svdhB
디렉토리 목록의 여러 설정들
IndexOrderDefault Ascending|Descending +Name|Date|Size|Description Ascending Name svdhB
디렉토리 목록의 기본 순서를 설정한다
IndexStyleSheet url-pathsvdhB
디렉토리 목록에 CSS 스타일쉬트를 추가한다
ISAPIAppendLogToErrors on|off off svdhB
Record HSE_APPEND_LOG_PARAMETER requests from +ISAPI extensions to the error log
ISAPIAppendLogToQuery on|off on svdhB
Record HSE_APPEND_LOG_PARAMETER requests from +ISAPI extensions to the query field
ISAPICacheFile file-path [file-path] +...svB
ISAPI .dll files to be loaded at startup
ISAPIFakeAsync on|off off svdhB
Fake asynchronous support for ISAPI callbacks
ISAPILogNotSupported on|off off svdhB
Log unsupported feature requests from ISAPI +extensions
ISAPIReadAheadBuffer size 49152 svdhB
Size of the Read Ahead Buffer sent to ISAPI +extensions
KeepAlive On|Off On svC
Enables HTTP persistent connections
KeepAliveTimeout seconds 15 svC
Amount of time the server will wait for subsequent +requests on a persistent connection
LanguagePriority MIME-lang [MIME-lang] +...svdhB
The precendence of language variants for cases where +the client does not express a preference
LDAPCacheEntries number 1024 sX
Maximum number of entries in the primary LDAP cache
LDAPCacheTTL seconds 600 sX
Time that cached items remain valid
LDAPOpCacheEntries number 1024 sX
Number of entries used to cache LDAP compare +operations
LDAPOpCacheTTL seconds 600 sX
Time that entries in the operation cache remain +valid
LDAPSharedCacheFile directory-path/filenamesX
Sets the shared memory chache file
LDAPSharedCacheSize bytes 102400 sX
Size in bytes of the shared-memory cache
LDAPTrustedCA directory-path/filenamesX
Sets the file containing the trusted Certificate Authority certificate or database
LDAPTrustedCAType typesX
Specifies the type of the Certificate Authority file
<Limit method [method] ... > ... + </Limit>svdhC
Restrict enclosed access controls to only certain HTTP +methods
<LimitExcept method [method] ... > ... + </LimitExcept>svdhC
Restrict access controls to all HTTP methods +except the named ones
LimitInternalRecursion number [number] 10 svC
Determine maximum number of internal redirects and nested +subrequests
LimitRequestBody bytes 0 svdhC
Restricts the total size of the HTTP request body sent +from the client
LimitRequestFields number 100 sC
Limits the number of HTTP request header fields that +will be accepted from the client
LimitRequestFieldsize bytessC
Limits the size of the HTTP request header allowed from the +client
LimitRequestLine bytes 8190 sC
Limit the size of the HTTP request line that will be accepted +from the client
LimitXMLRequestBody bytes 1000000 svdhC
Limits the size of an XML-based request body
Listen [IP-address:]portnumbersM
IP addresses and ports that the server +listens to
ListenBacklog backlogsM
Maximum length of the queue of pending connections
LoadFile filename [filename] ...sE
지정한 목적파일이나 라이브러리를 읽어들인다
LoadModule module filenamesE
목적파일이나 라이브러리를 읽어들이고, 사용가능한 +모듈 목록에 추가한다
<Location + URL-path|URL> ... </Location>svC
Applies the enclosed directives only to matching +URLs
<LocationMatch + regex> ... </LocationMatch>svC
Applies the enclosed directives only to regular-expression +matching URLs
LockFile filename logs/accept.lock sM
Location of the accept serialization lock file
LogFormat format|nickname +[nickname] "%h %l %u %t \"%r\" +svB
Describes a format for use in a log file
LogLevel level warn svC
Controls the verbosity of the ErrorLog
MaxClients numbersM
Maximum number of child processes that will be created +to serve requests
MaxKeepAliveRequests number 100 svC
Number of requests allowed on a persistent +connection
MaxMemFree KBytes 0 sM
Maximum amount of memory that the main allocator is allowed +to hold without calling free()
MaxRequestsPerChild number 10000 sM
Limit on the number of requests that an individual child server +will handle during its life
MaxRequestsPerThread number 0 sM
한 쓰레드가 실행하는 동안 처리할 요청개수 한계
MaxSpareServers number 10 sM
Maximum number of idle child server processes
MaxSpareThreads numbersM
Maximum number of idle threads
MaxThreads number 2048 sM
Set the maximum number of worker threads
MaxThreadsPerChild number 64 sM
Maximum number of threads per child process
MCacheMaxObjectCount value 1009 sX
The maximum number of objects allowed to be placed in the +cache
MCacheMaxObjectSize bytes 10000 sX
The maximum size (in bytes) of a document allowed in the +cache
MCacheMaxStreamingBuffer size_in_bytes the smaller of 1000 +sX
Maximum amount of a streamed response to buffer in memory +before declaring the response uncacheable
MCacheMinObjectSize bytes 0 sX
The minimum size (in bytes) of a document to be allowed in the +cache
MCacheRemovalAlgorithm LRU|GDSF GDSF sX
The algorithm used to select documents for removal from the +cache
MCacheSize KBytes 100 sX
The maximum amount of memory used by the cache in +KBytes
MetaDir directory .web svdhE
CERN 메타정보를 찾을 디렉토리 이름
MetaFiles on|off off svdhE
CERN 메타파일을 처리한다
MetaSuffix suffix .meta svdhE
CERN 메타정보를 저장하는 파일의 접미사
MimeMagicFile file-pathsvE
Enable MIME-type determination based on file contents +using the specified magic file
MinSpareServers number 5 sM
Minimum number of idle child server processes
MinSpareThreads numbersM
Minimum number of idle threads available to handle request +spikes
MMapFile file-path [file-path] ...sX
Map a list of files into memory at startup time
ModMimeUsePathInfo On|Off Off dB
Tells mod_mime to treat path_info +components as part of the filename
MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers +[Handlers|Filters] NegotiatedOnly svdhB
The types of files that will be included when searching for +a matching file with MultiViews
NameVirtualHost addr[:port]sC
Designates an IP address for name-virtual +hosting
NoProxy host [host] ...svE
Hosts, domains, or networks that will be connected to +directly
NumServers number 2 sM
Total number of children alive at the same time
NWSSLTrustedCerts filename [filename] ...sB
List of additional client certificates
Options + [+|-]option [[+|-]option] ... All svdhC
Configures what features are available in a particular +directory
Order ordering Deny,Allow dhB
기본적으로 접근을 허용할지 거부할지 여부와 +Allow와 Deny +처리순서를 정한다.
PassEnv env-variable [env-variable] +...svdhB
쉘에서 환경변수를 가져온다
PidFile filename logs/httpd.pid sM
File where the server records the process ID +of the daemon
ProtocolEcho On|OffsvX
echo 서버를 키고 끈다
<Proxy wildcard-url> ...</Proxy>svE
Container for directives applied to proxied resources
ProxyBadHeader IsError|Ignore|StartBody IsError svE
Determines how to handle bad header lines in a +response
ProxyBlock *|word|host|domain +[word|host|domain] ...svE
Words, hosts, or domains that are banned from being +proxied
ProxyDomain DomainsvE
Default domain name for proxied requests
ProxyErrorOverride On|Off Off svE
Override error pages for proxied content
ProxyIOBufferSize bytes 8192 svE
Determine size of internal data throughput buffer
<ProxyMatch regex> ...</ProxyMatch>svE
Container for directives applied to regular-expression-matched +proxied resources
ProxyMaxForwards number 10 svE
Maximium number of proxies that a request can be forwarded +through
ProxyPass [path] !|urlsvdE
Maps remote servers into the local server URL-space
ProxyPassReverse [path] urlsvdE
Adjusts the URL in HTTP response headers sent from a reverse +proxied server
ProxyPreserveHost On|Off Off svE
Use incoming Host HTTP request header for proxy +request
ProxyReceiveBufferSize bytes 0 svE
Network buffer size for proxied HTTP and FTP +connections
ProxyRemote match remote-serversvE
Remote proxy used to handle certain requests
ProxyRemoteMatch regex remote-serversvE
Remote proxy used to handle requests matched by regular +expressions
ProxyRequests On|Off Off svE
Enables forward (standard) proxy requests
ProxyTimeout seconds 300 svE
Network timeout for proxied requests
ProxyVia On|Off|Full|Block Off svE
Information provided in the Via HTTP response +header for proxied requests
ReadmeName filenamesvdhB
파일목록 마지막에 삽입할 파일의 이름
Redirect [status] URL-path +URLsvdhB
클라이언트가 다른 URL에 접속하도록 요청하는 외부 +리다이렉션을 보낸다
RedirectMatch [status] regex +URLsvdhB
현재 URL이 정규표현식에 해당하면 외부 리다이렉션을 +보낸다
RedirectPermanent URL-path URLsvdhB
클라이언트가 다른 URL에 접속하도록 요청하는 외부 +영구 리다이렉션을 보낸다
RedirectTemp URL-path URLsvdhB
클라이언트가 다른 URL에 접속하도록 요청하는 외부 +임시 리다이렉션을 보낸다
RemoveCharset extension [extension] +...vdhB
Removes any character set associations for a set of file +extensions
RemoveEncoding extension [extension] +...vdhB
Removes any content encoding associations for a set of file +extensions
RemoveHandler extension [extension] +...vdhB
Removes any handler associations for a set of file +extensions
RemoveInputFilter extension [extension] +...vdhB
Removes any input filter associations for a set of file +extensions
RemoveLanguage extension [extension] +...vdhB
Removes any language associations for a set of file +extensions
RemoveOutputFilter extension [extension] +...vdhB
Removes any output filter associations for a set of file +extensions
RemoveType extension [extension] +...vdhB
Removes any content type associations for a set of file +extensions
RequestHeader set|append|add|unset header +[value] [env=[!]variable]svdhE
Configure HTTP request headers
Require entity-name [entity-name] ...dhC
Selects which authenticated users can access +a resource
RewriteBase URL-pathdhE
Sets the base URL for per-directory rewrites
RewriteCond + TestString CondPatternsvdhE
Defines a condition under which rewriting will take place +
RewriteEngine on|off off svdhE
Enables or disables runtime rewriting engine
RewriteLock file-pathsE
Sets the name of the lock file used for RewriteMap +synchronization
RewriteLog file-pathsvE
Sets the name of the file used for logging rewrite engine +processing
RewriteLogLevel Level 0 svE
Sets the verbosity of the log file used by the rewrite +engine
RewriteMap MapName MapType:MapSource +svE
Defines a mapping function for key-lookup
RewriteOptions Options MaxRedirects=10 svdhE
Sets some special options for the rewrite engine
RewriteRule + Pattern SubstitutionsvdhE
Defines rules for the rewriting engine
RLimitCPU seconds|max [seconds|max]svdhC
Limits the CPU consumption of processes launched +by Apache children
RLimitMEM bytes|max [bytes|max]svdhC
Limits the memory consumption of processes launched +by Apache children
RLimitNPROC number|max [number|max]svdhC
Limits the number of processes that can be launched by +processes launched by Apache children
Satisfy Any|All All dhC
Interaction between host-level access control and +user authentication
ScoreBoardFile file-path logs/apache_status sM
Location of the file used to store coordination data for +the child processes
Script method cgi-scriptsvdB
특정 요청메서드에 대해 CGI 스크립트를 +사용한다.
ScriptAlias URL-path +file-path|directory-pathsvB
URL을 특정 파일시스템 장소로 대응하고 대상이 CGI +스크립트라고 알린다
ScriptAliasMatch regex +file-path|directory-pathsvB
정규표현식을 사용하여 URL을 특정 파일시스템 장소로 +대응하고 대상이 CGI 스크립트라고 알린다
ScriptInterpreterSource Registry|Registry-Strict|Script Script svdhC
Technique for locating the interpreter for CGI +scripts
ScriptLog file-pathsvB
CGI 스크립트 오류로그파일의 위치
ScriptLogBuffer bytes 1024 svB
스크립트 로그에 기록할 PUT 혹은 POST 요청의 최대량
ScriptLogLength bytes 10385760 svB
CGI 스크립트 로그파일의 크기 제한
ScriptSock file-path logs/cgisock svB
cgi 데몬과 통신을 위해 사용할 소켓의 이름
SecureListen [IP-address:]portnumber +Certificate-Name [MUTUAL]sB
Enables SSL encryption for the specified port
SendBufferSize bytes 0 sM
TCP buffer size
ServerAdmin email-address|URLsvC
Email address that the server includes in error +messages sent to the client
ServerAlias hostname [hostname] ...vC
Alternate names for a host used when matching requests +to name-virtual hosts
ServerLimit numbersM
Upper limit on configurable number of processes
ServerName fully-qualified-domain-name[:port]svC
Hostname and port that the server uses to identify +itself
ServerPath URL-pathvC
Legacy URL pathname for a name-based virtual host that +is accessed by an incompatible browser
ServerRoot directory-path /usr/local/apache sC
Base directory for the server installation
ServerSignature On|Off|EMail Off svdhC
Configures the footer on server-generated documents
ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full Full sC
Configures the Server HTTP response +header
SetEnv env-variable valuesvdhB
환경변수를 설정한다
SetEnvIf attribute + regex [!]env-variable[=value] + [[!]env-variable[=value]] ...svdhB
요청의 성질에 따라 환경변수를 설정한다
SetEnvIfNoCase attribute regex + [!]env-variable[=value] + [[!]env-variable[=value]] ...svdhB
대소문자를 구별하지않고 요청의 성질에 따라 환경변수를 +설정한다
SetHandler handler-name|NonesvdhC
Forces all matching files to be processed by a +handler
SetInputFilter filter[;filter...]svdhC
Sets the filters that will process client requests and POST +input
SetOutputFilter filter[;filter...]svdhC
Sets the filters that will process responses from the +server
SSIEndTag tag "-->" svB
String that ends an include element
SSIErrorMsg message "[an error occurred +svdhB
Error message displayed when there is an SSI +error
SSIStartTag tag "<!--#" svB
String that starts an include element
SSITimeFormat formatstring "%A, %d-%b-%Y %H:%M +svdhB
Configures the format in which date strings are +displayed
SSIUndefinedEcho string "(none)" svdhB
String displayed when an unset variable is echoed
SSLCACertificateFile file-pathsvE
File of concatenated PEM-encoded CA Certificates +for Client Auth
SSLCACertificatePath directory-pathsvE
Directory of PEM-encoded CA Certificates for +Client Auth
SSLCARevocationFile file-pathsvE
File of concatenated PEM-encoded CA CRLs for +Client Auth
SSLCARevocationPath directory-pathsvE
Directory of PEM-encoded CA CRLs for +Client Auth
SSLCertificateChainFile file-pathsvE
File of PEM-encoded Server CA Certificates
SSLCertificateFile file-pathsvE
Server PEM-encoded X.509 Certificate file
SSLCertificateKeyFile file-pathsvE
Server PEM-encoded Private Key file
SSLCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhE
Cipher Suite available for negotiation in SSL +handshake
SSLEngine on|off off svE
SSL Engine Operation Switch
SSLMutex type none sE
Semaphore for internal mutual exclusion of +operations
SSLOptions [+|-]option ...svdhE
Configure various SSL engine run-time options
SSLPassPhraseDialog type builtin sE
Type of pass phrase dialog for encrypted private +keys
SSLProtocol [+|-]protocol ... all svE
Configure usable SSL protocol flavors
SSLProxyCACertificateFile file-pathsvE
File of concatenated PEM-encoded CA Certificates +for Remote Server Auth
SSLProxyCACertificatePath directory-pathsvE
Directory of PEM-encoded CA Certificates for +Remote Server Auth
SSLProxyCARevocationFile file-pathsvE
File of concatenated PEM-encoded CA CRLs for +Remote Server Auth
SSLProxyCARevocationPath directory-pathsvE
Directory of PEM-encoded CA CRLs for +Remote Server Auth
SSLProxyCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhE
Cipher Suite available for negotiation in SSL +proxy handshake
SSLProxyEngine on|off off svE
SSL Proxy Engine Operation Switch
SSLProxyMachineCertificateFile filenamesE
File of concatenated PEM-encoded client certificates and keys to be used by the proxy
SSLProxyMachineCertificatePath directorysE
Directory of PEM-encoded client certificates and keys to be used by the proxy
SSLProxyProtocol [+|-]protocol ... all svE
Configure usable SSL protocol flavors for proxy usage
SSLProxyVerify level none svdhE
Type of remote server Certificate verification
SSLProxyVerifyDepth number 1 svdhE
Maximum depth of CA Certificates in Remote Server +Certificate verification
SSLRandomSeed context source +[bytes]sE
Pseudo Random Number Generator (PRNG) seeding +source
SSLRequire expressiondhE
Allow access only when an arbitrarily complex +boolean expression is true
SSLRequireSSLdhE
Deny access when SSL is not used for the +HTTP request
SSLSessionCache type none sE
Type of the global/inter-process SSL Session +Cache
SSLSessionCacheTimeout seconds 300 svE
Number of seconds before an SSL session expires +in the Session Cache
SSLVerifyClient level none svdhE
Type of Client Certificate verification
SSLVerifyDepth number 1 svdhE
Maximum depth of CA Certificates in Client +Certificate verification
StartServers numbersM
Number of child server processes created at startup
StartThreads numbersM
Number of threads created on startup
SuexecUserGroup User GroupsvE
CGI 프로그램이 사용할 사용자와 그룹 권한
ThreadLimit numbersM
Sets the upper limit on the configurable number of threads +per child process
ThreadsPerChild numbersM
Number of threads created by each child process
ThreadStackSize sizesM
The size in bytes of the stack used by threads handling +client connections
TimeOut seconds 300 sC
Amount of time the server will wait for +certain events before failing a request
TransferLog file|pipesvB
Specify location of a log file
TypesConfig file-path conf/mime.types sB
The location of the mime.types file
UnsetEnv env-variable [env-variable] +...svdhB
환경변수를 제거한다
UseCanonicalName On|Off|DNS On svdC
Configures how the server determines its own name and +port
User unix-userid #-1 sM
The userid under which the server will answer +requests
UserDir directory-filename public_html svB
사용자별 디렉토리 위치
VirtualDocumentRoot interpolated-directory|none none svE
Dynamically configure the location of the document root +for a given virtual host
VirtualDocumentRootIP interpolated-directory|none none svE
Dynamically configure the location of the document root +for a given virtual host
<VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost>sC
Contains directives that apply only to a specific +hostname or IP address
VirtualScriptAlias interpolated-directory|none none svE
Dynamically configure the location of the CGI directory for +a given virtual host
VirtualScriptAliasIP interpolated-directory|none none svE
Dynamically configure the location of the cgi directory for +a given virtual host
Win32DisableAcceptExsM
Use accept() rather than AcceptEx() to accept network connections
XBitHack on|off|full off svdhB
Parse SSI directives in files with the execute bit +set
+
+

가능한 언어:  de  | + en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/quickreference.xml.ko b/docs/manual/mod/quickreference.xml.ko index fd22d7e485..a81e549887 100644 --- a/docs/manual/mod/quickreference.xml.ko +++ b/docs/manual/mod/quickreference.xml.ko @@ -3,7 +3,7 @@ [ ] > - + +아파치 EBCDIC 포팅 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Platform Specific Notes

아파치 EBCDIC 포팅

+
+

가능한 언어:  en  | + ko 

+
+ + +
이 문서는 아파치 웹서버 2.0 버전에서 + 변경된 내용을 담고있지 않다. 아직도 유효한 정보가 있지만, + 주의해서 사용하길 바란다. +
+ +
+
+
top
+
+

아파치 EBCDIC 포팅 개요

+ + + +

아파치 웹서버는 1.3 버전때 처음으로 EBCDIC 문자집합을 + 기본 문자집합으로 사용하는 (비-ASCII) 메인플레임 컴퓨터로 + 포팅되었다.

+ +

(BS2000/OSD + 운영체제를 사용하는 SIEMENS 계열 메인플레임을 말한다. + 이 메인플레임 운영체제에는 현재 SVR4계열의 POSIX 하위시스템이 + 있다).

+ +

포팅은 처음에 다음과 같은 목적에서 시작되었다

+ + + +

이 문서는 포팅시 여러 설계상 결정의 이유를 설명한다.

+ +
top
+
+

설계 목표

+ + + +

EBCDIC 포팅의 목적중 하나는 새로운 서버로 전환을 유도하고 + 쉽게 전환할 수 있도록 가능한 (EBCDIC) CERN 서버와 호환성을 + 유지하는 것이다. 그래서 HTML 문서가 (이전 CERN 서버가 인식하는 + 유일한 형식인) ASCII와 (POSIX 하위시스템의 기본 문서 형식. + 그러므로 grep이나 sed 같은 POSIX + 도구를 사용할 수 있는 현실적인 형식인) EBCDIC 중 어느 형식인지 + 설정할 수 있어야 한다. 현재 해결책은 아파치 서버가 중간에서 + 문서를 가로채서 문서의 형식을 파악하는 "가상 MIME 형식"이다 + (아래 참고). 다음 버전에서는 변환해야할 모든 문서에 + "ebcdic-handler"를 정의하는 방법으로 문제를 해결할 것이다.

+ +
top
+
+

기술적 해결책

+ + + +

아파치가 BUFF 자료형과 메써드를 사용하여 모든 입출력을 + 하므로 가장 쉬운 방법은 BUFF 처리 함수에 변환기능을 추가하는 + 것이다. 언제든지 변환할 수 있어야 하기때문에 BUFF 객체를 + 변환해야 하는지 알려주는 BUFF 표시를 추가했다. 이 표시는 + HTTP 프로토콜의 여러 단계에서 변경될 수 있다:

+ + + +
top
+
+

포팅에 대해서

+ + + +
    +
  1. +

    소스의 변화는 두가지 #ifdef로 구분할 + 수 있다:

    + +
    +
    #ifdef + CHARSET_EBCDIC
    + +
    +

    모든 EBCDIC기반 컴퓨터에 필요한 코드. 문자변환, + 두 문자집합간의 연속된 문자값 차이, 어떤 HTTP 프로토콜 + 부분이 변환되야 하는지를 알려주는 표시 등.

    +
    + +
    #ifdef _OSD_POSIX
    + +
    +

    SIEMENS BS2000/OSD 메인플레임 플레폼에만 필요한 + 코드. BS2000/OSD 플레폼에만 필요한 헤더파일 차이와 + 소켓 구현 문제를 다룬다.

    +
    +
    +
    2. + +
  2. +

    소켓 수준에서 ASCII와 EBCDIC간 변화는 (BS2000 POSIX에는 + 이 기능을 지원하는 소켓 옵션이 있다) HTTP 프로토콜 수준에서 + 전송되는 자료에 프로토콜관련 문자열과 프로토콜과 무관한 + 일반파일이 섞여있기때문에 의도적으로 사용하지 + 않았다. HTTP 프로토콜 문자열은 (GET + 요청, Header: 줄, 기타 정보 등.) 항상 ASCII + 형식이고, 파일전송 부분은 (즉, GIF 그림, CGI + 출력 등.) 서버가 항상 "변환하지않고 그냥" 보내야 + 한다. 서버 코드는 "프로토콜 문자열"과 "일반 자료"를, + 문자열에는 bgets()나 rvputs(), + 바이너리 자료에는 bgets()나 + rvputs() 함수를 사용하여 구별한다. 그러므로 + 무조건 모든 것을 변환하는 것은 적절하지 않다.

    + +

    (물론 문자파일의 경우 EBCDIC 문서를 항상 ASCII로 + 서비스하도록 준비해야 한다)

    +
    3. + +
  3. +

    그래서 포팅에는 (컴파일러가 EBCDIC 문자열로 변환한) + 서버 내부 문자열과 서버가 생성한 문서를 기본 프로토콜 + 수준에서 변환하는 기능이 있다. 서버 코드에 산재된 ASCII + escape문자 \012와 \015는 예외다: + 이들이 이미 ASCII \n과 \r의 + 바이너리 값이기때문에 ASCII로 두번 변환하면 안된다. + 이 예외는 서버가 생성한 문자열에만 적용된다; 외부 + EBCDIC 문서는 ASCII 줄바꿈문자를 포함하면 안된다.

    +
    4. + +
  4. +

    BUFF 관리함수를 사용하는 방법을 살펴본 후 나는 모든 + puts/write/get/gets가 거치게되는 "ebcdic/ascii 변환 + 계층"을 추가하고, 동적으로 변환유무를 설정할 수 있는 + 변환 표시를 추가했다. 문서가 원본(파일이나 CGI 출력)에서 + 대상(요청한 클라이언트)으로 이동할때 항상 이 계층을 + 두번 지난다: 파일 -> 아파치, 아파치 + -> 클라이언트.

    + +

    서버는 이제 EBCDIC 형식으로 된 CGI 스크립트 출력의 + 헤더줄을 읽고, 나머지 스크립트 출력이 ASCII임을 알아낼 + 수 있다 (WWW 방문자수를 세는 프로그램과 같은 경우: 문서 + 내용은 GIF 그림이다). 기본 EBCDIC 형식으로 모든 헤더를 + 처리한다; 그런 다음 서비스할 문서의 type에 따라 서버는 + 문서 내용이 이미 ASCII인지 혹은 EBCDIC에서 변환을 해야 + 하는지 결정한다.

    +
    5. + +
  5. +

    (MIME type이 text/plain, text/html 등) 내용이 + 일반 문자인 문서를 암묵적으로 ASCII로 변환하거나, (사용자에게 + 빠르게 서비스하기위해 미리 문서를 ASCII 형식으로 저장하였거나 + NFS로 마운트한 디렉토리에 파일이 있는 경우) 변환없이 + 서비스할 수 있다.

    + +

    예:

    + +

    이름이 .ahtml로 끝나는 파일을 암묵적인 + 변환없이 ASCII text/html 문서로 (그리고 + .ascii 확장자는 ASCII + text/plain으로) 서비스하려면 다음 지시어를 + 사용한다:

    + +

    + AddType text/x-ascii-html .ahtml
    + AddType text/x-ascii-plain .ascii +

    + +

    또, text/foo 식의 MIME type을 + AddType "text/x-ascii-foo" + 설정하여 "일반 ASCII"로 서비스할 수 있다.

    +
    6. + +
  6. +

    내용이 일반 문자가 아닌 문서는 변환없이 항상 "바이너리"로 + 서비스한다. 예를 들어, GIF/ZIP/AU 파일형식에 + 가장 적합한 선택이다. 물론 사용자는 "rcp -b" + 바이너리 옵션을 사용하여 파일을 메인플레임 호스트로 + 복사했어야 한다.

    +
    7. + +
  7. +

    서버파싱 파일은 항상 컴퓨터가 사용하는 기본 형식으로 + (즉, EBCDIC) 저장되었다고 가정하고, 처리후에 + 변환한다.

    +
    8. + +
  8. +

    CGI 출력의 경우 CGI 스크립트가 변환이 필요한지 결정한다: + 적절한 Content-Type을 설정하여, 문자파일은 변환하고, + GIF 출력은 변환없이 보낼 수 있다. 우리가 포팅한 wwwcount + 프로그램이 후자의 경우다.

    +
    9. + +
+ +
top
+
+

문서 저장에 대해서

+ + + +

바이너리 파일

+ + + +

서버는 Content-Type:이 text/로 + 시작하는 않는 파일을 바이너리 파일로 간주하여 + 어떤 변환도 하지 않는다. 바이너리 파일에는 GIF 그림, gzip으로 + 압축한 파일 등이 있다.

+ +

메인플레임 호스트와 유닉스 혹은 윈도우즈 PC간에 바이너리 + 파일을 전송할 때는 ftp "binary" (TYPE I) 명령어나 + 메인플레임 호스트에서 (유닉스 rcp는 + -b 옵션을 지원하지 않는다) rcp -b + 명령어를 반드시 사용하라.

+ + + +

문자 문서

+ + + +

기본적으로 서버는 문자파일이 (즉, + Content-Type:이 text/로 시작하는 + 모든 파일) 호스트의 기본 문자집합인 EBCDIC으로 저장되었다고 + 가정한다.

+ + + +

Server Side Include 문서

+ + + +

SSI 문서는 현재 EBCDIC 형식으로만 저장해야 한다. 처리하기 + 전에 ASCII를 변환하지 않는다.

+ + + +
top
+
+

아파치 모듈의 상태

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
모듈상태비고
core+ +
mod_access+ +
mod_actions+ +
mod_alias+ +
mod_asis+ +
mod_auth+ +
mod_auth_anon+ +
mod_auth_dbm?자체 libdb.a를 사용하여
mod_autoindex+ +
mod_cern_meta? +
mod_cgi+ +
mod_digest+ +
mod_dir+ +
mod_so-공유라이브러리가 없음
mod_env+ +
mod_example-(시험 단계)
mod_expires+ +
mod_headers+ +
mod_imap+ +
mod_include+ +
mod_info+ +
mod_log_agent+ +
mod_log_config+ +
mod_log_referer+ +
mod_mime+ +
mod_mime_magic?아직 포팅안됨
mod_negotiation+ +
mod_proxy+ +
mod_rewrite+테스트안됨
mod_setenvif+ +
mod_speling+ +
mod_status+ +
mod_unique_id+ +
mod_userdir+ +
mod_usertrack?테스트안됨
+ +
top
+
+

제삼자가 만든 모듈의 상태

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
모듈상태비고
mod_jserv + -JAVA는 포팅중이다.
mod_php3+mod_php3는 LDAP, GD, FreeType 라이브러리와 + 함께 잘 동작한다.
mod_put?테스트안됨
mod_session-테스트안됨
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/ebcdic.xml.ko b/docs/manual/platform/ebcdic.xml.ko index c8951ecafb..7a98010f18 100644 --- a/docs/manual/platform/ebcdic.xml.ko +++ b/docs/manual/platform/ebcdic.xml.ko @@ -1,7 +1,7 @@ - + +플래폼별 설명 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1

플래폼별 설명

+
+

가능한 언어:  en  | + ko 

+
+
+
+
top
+
+

Microsoft Windows

+ + + +
+
아파치 사용법
+
+

이 문서는 Microsoft Windows에서 아파치 2.0을 설치, + 설정, 실행하는 방법을 설명한다.

+ +

문서: Microsoft Windows에서 + 아파치 사용법

+
+
+ +
+
아파치 컴파일
+
+

아파치를 컴파일하기 전에 주의할 점이 많다. 이 문서는 + 이점을 설명한다.

+ +

문서: Microsoft Windows용 아파치 컴파일

+
+
+ +
top
+
+

기타 플래폼

+ + + +
+
Novell NetWare
+
+

이 문서는 Novell NetWare 5.1 이상에서 아파치 2.0을 + 설치, 설정, 실행하는 방법을 설명한다.

+ +

문서: Novell NetWare에서 아파치 + 사용하기

+
+
+ +
+
EBCDIC
+
+

아파치 웹서버는 1.3 버전때 처음으로 EBCDIC 문자집합을 + 기본 문자집합으로 사용하는 (비-ASCII) 메인플레임 컴퓨터로 + 포팅되었다.

+ +
경고: 이 문서는 + 아파치 웹서버 2.0 버전에서 변경된 내용을 담고있지 않다. + 아직도 유효한 정보가 있지만, 주의해서 사용하길 바란다.
+ +

문서: 아파치 EBCDIC 포팅

+
+
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/index.xml.ko b/docs/manual/platform/index.xml.ko index b078374b42..c15f3669f2 100644 --- a/docs/manual/platform/index.xml.ko +++ b/docs/manual/platform/index.xml.ko @@ -1,7 +1,7 @@ - + +Novell NetWare에서 아파치 사용하기 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Platform Specific Notes

Novell NetWare에서 아파치 사용하기

+
+

가능한 언어:  en  | + ko 

+
+ + +

이 문서는 Novell NetWare 6.0 이상에서 아파치 2.0을 설치, + 설정, 실행하는 방법을 설명한다. 버그를 찾았거나 다른 방법으로 + 돕고싶다면, 버그 + 보고 페이지를 이용하길 바란다.

+ +

버그 보고 페이지나 dev-httpd 메일링리스트는 아파치 설정과 + 실행에 대한 질문을 답하지 않는다. 버그를 보고하기 + 전에 먼저 이 문서와 자주 물어보는 질문 + (FAQ) 페이지, 다른 관련문서를 살펴봐라. 그래도 궁금한 + 점이나 문제가 있다면, NetWare에서 아파치 사용에 대한 어렵고 + 새로운 질문을 답해줄 많은 아파치 사용자가 있는 + novell.devsup.webserver 뉴스그룹에 글을 올리길 바란다.

+ +

이 문서는 바이너리 배포본으로 아파치를 설치했다고 가정한다. + (아마도 개발에 도움을 주거나 버그를 찾기위해) 직접 아파치를 + 컴파일하려면 아래 NetWare에서 아파치 + 컴파일하기 절을 참고하라.

+ +
+
+
top
+
+

요구조건

+ + + +

아파치 2.0은 NetWare 6.0 service pack 3 이상에서 동작하도록 + 설계되었다. SP3보다 낮은 service pack을 사용한다면 최신 + NetWare + Libraries for C (LibC)를 설치해야 한다.

+ +

NetWare service pack은 여기에 + 있다.

+ +

최신 service pack이나 최신 버전 NetWare + Libraries for C (LibC)를 설치했다면 NetWare 5.1 환경에서도 + NetWare용 아파치 2.0을 실행할 수 있다. 경고: + NetWare용 아파치 2.0은 이 환경을 고려하지 않았고 테스트하지 + 않았다.

+ +
top
+
+

NetWare용 아파치 다운받기

+ + + +

아파치 최신 버전에 대한 정보는 http://www.apache.org/에서 + (아파치 웹서버) 찾을 수 있다. 여기에는 현재 버전과 최근 + 알파/베타테스트 버전, 미러 웹사이트와 ftp 사이트 정보가 + 있다. NetWare용 아파치 2.0의 최신 바이너리 배포본은 여기에서 + 다운받을 수 있다.

+ +
top
+
+

NetWare용 아파치 설치하기

+ + + +

현재 NetWare용 아파치 설치프로그램은 없다. NetWare용 + 아파치 2.0 소스를 직접 컴파일한다면 파일을 서버로 직접 + 복사해줘야 한다.

+ +

바이너리로 다운받은 NetWare용 아파치를 설치하는 과정은 + 다음과 같다 (sys:/apache2에 설치한다고 가정한다):

+ + + +

직접 소스를 컴파일한 경우 NetWare에 아파치를 설치하는 + 방법은 다음과 같다 (sys:/apache2에 설치한다고 + 가정한다):

+ + + +

기본 SYS 볼륨이 아닌 다른 볼륨에도 아파치를 + 설치할 수 있다.

+ +

makefile 명령어에 "install" 키워드를 사용하면 컴파일시 + 자동으로 DIST 하위디렉토리에 완전한 배포본을 + 만든다. makefile로 만든 배포본을 NetWare 볼륨 최상위 디렉토리로 + 복사하면 아파치가 설치된다 (아래 NetWare용 + 아파치 컴파일하기 참고).

+ +
top
+
+

NetWare용 아파치 실행하기

+ + + +

아파치를 시작하려면 콘솔에서 apache를 입력하면 + 된다. 그러면 운영체제 주소영역에 아파치를 읽어들인다. + 보호주소영역에 아파치를 읽어들이려면 다음과 같이 load 명령어로 + 주소영역을 지정한다:

+ +

+ load address space = apache2 apache2 +

+ +

그러면 아파치를 apache2라는 주소영역에 읽어들인다. + NetWare는 여러 아파치를 각각 다른 보호주소영역에 읽어들여서 + 여러 아파치를 동시에 실행할 수 있다.

+ +

아파치가 시작하면 (설정파일에서 Listen 지시어를 수정하지 + 않는한) 포트 80번을 기다린다. 브라우저를 시작하여 서버명 + 혹은 서버 주소를 입력하면 서버에 접속하여 기본페이지에 + 접근한다. 아파치 설명서 링크가 있는 환영페이지가 나와야 + 한다. 아무 일도 없거나 오류가 발생하면 logs + 디렉토리에 있는 error_log 파일을 살펴봐라.

+ +

기본 설치가 동작하면 conf 디렉토리에 있는 + 파일을 적절히 설정한다.

+ +

운영체제 주소영역에서 실행중인 아파치를 내릴려면 콘솔에 + 다음과 같이 입력한다:

+ +

+ unload apache2 +

+ +

혹은

+ +

+ apache2 shutdown +

+ +

보호주소영역에서 아파치를 실행했다면 unload 명령어에 + 주소영역을 지정한다:

+ +

+ unload address space = apache2 apache2 +

+ +

아파치가 설정파일 위치를 찾는 방법을 알아두어야 한다. + 명령행에서 설정파일을 지정하는 방법은 두가지다:

+ + + +

+ apache2 -f "vol:/my server/conf/my.conf" +

+ +

+ apache -f test/test.conf +

+ +

이 경우 설정파일은 올바른 ServerRoot를 설정해야 한다.

+ +

-f로 설정파일명을 지정하지 않으면, 아파치는 + 서버에 컴파일된 파일명을 (보통 conf/httpd.conf) + 사용한다. -V 옵션으로 아파치를 시작하면 + SERVER_CONFIG_FILE이라는 항목을 보여준다. + 아파치는 다음 순서대로 ServerRoot를 찾는다:

+ + + +

서버에 컴파일된 server root는 보통 + sys:/apache2이다. -V 옵션으로 + 아파치를 시작하면 HTTPD_ROOT라는 항목을 보여준다.

+ +

NetWare용 아파치 2.0에는 실행중인 웹서버를 죽이거나 정보를 + 알려주는 명령행 지시어가 있다. 이들 지시어는 아파치 동작중에만 + 사용할 수 있다. 지시어 앞에는 APACHE2 키워드를 + 붙여야 한다.

+ +
+
RESTART
+
모든 쓰레드가 쉬는 상태일때 아파치를 죽이고, 설정파일을 + 다시 읽은후 새로운 설정에 따라 worker 쓰레드들을 재시작한다.
+ +
VERSION
+
현재 실행중인 아파치 버전 정보를 출력한다.
+ +
MODULES
+
기본 모듈과 외부 모듈 목록을 출력한다.
+ +
DIRECTIVES
+
모든 지시어 목록을 출력한다.
+ +
SETTINGS
+
콘솔에 쓰레드 상태 표시를 보이거나 없앤다. 상태를 + 보이면, 아파치 콘솔창에 동작하는 쓰레드들의 상태가 나온다.
+ +
SHUTDOWN
+
실행중인 아파치 웹서버를 죽인다.
+ +
HELP
+
실행 옵션들을 설명한다.
+
+ +

기본적으로 이 지시어들은 운영체제 주소영역에서 실행중인 + 아파치를 대상으로 한다. 아파치가 보호주소영역에서 실행중이라면, + -p와 주소영역 이름을 추가한다. 더 많은 정보를 보려면 명령행에 + "apache2 Help"를 입력한다.

+ +
top
+
+

NetWare용 아파치 설정하기

+ + + +

아파치는 보통 conf 디렉토리에 있는 설정파일로 + 설정한다. 이 파일은 유닉스용과 같지만, NetWare용 아파치에는 + 조금 다른 지시어들이 있다. 사용가능한 모든 지시어에 대해서는 + 아파치 문서를 참고하라.

+ +

NetWare용 아파치의 주된 차이점은:

+ + + +

이외의 NetWare 전용 지시어들:

+ + + + + + + + + +
top
+
+

Netware용 아파치 컴파일하기

+ + + +

아파치를 컴파일하려면 MetroWerks CodeWarrior 6.x 이상이 + 필요하다. 아파치를 컴파일하면 어떤 Netware 볼륨에라도 설치할 + 수 있다. 기본값은 sys:/Apache2 디렉토리다.

+ +

서버를 실행하기 전에 conf 디렉토리를 작성해야 + 한다. 배포본의 conf 디렉토리에 있는 + HTTPD-STD.CONF 파일명을 HTTPD.CONF로 + 변경한다. HTTPD.CONF 파일에서 @@Value@@ + 표시를 찾아서 적절한 설정으로 대체한다. conf/magic과 + conf/mime.types 파일도 복사한다. 아니면 makefile을 + 실행할때 install 키워드를 사용하면 완전한 배포본을 + 만든다.

+ +

요구사항:

+ + + +

NetWare용 아파치 2.0을 컴파일하려면 다음 개발도구가 + 필요하다:

+ + + + + +

NetWare makefile을 사용하여 아파치 컴파일하기:

+ + + + + + + +

추가 make 옵션

+ + + + + + + +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/netware.xml.ko b/docs/manual/platform/netware.xml.ko index edb7d2871b..075cb8410e 100644 --- a/docs/manual/platform/netware.xml.ko +++ b/docs/manual/platform/netware.xml.ko @@ -1,7 +1,7 @@ - + +HPUX에서 고성능 웹서버 실행하기 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Platform Specific Notes

HPUX에서 고성능 웹서버 실행하기

+
+

가능한 언어:  en  | + ko 

+
+ + +
+Date: Wed, 05 Nov 1997 16:59:34 -0800
+From: Rick Jones <raj@cup.hp.com>
+Reply-To: raj@cup.hp.com
+Organization: Network Performance
+Subject: HP-UX tuning tips
+
+ +

이 글은 성능향상 페이지에 추가할 HP-UX 성능향상 팁이다.

+ +

HP-UX 9.X는: 10.20으로 업그레이드하라
+ HP-UX 10.[00|01|10]은: 10.20으로 업그레이드하라

+ +

HP-UX 10.20은:

+ +

최근 ARPA Transport 패치 모음을 설치한다. 그러면 TCP + 연결찾기 해쉬테이블 크기를 설정할 수 있다. 기본값은 + 256 개이고, 2의 거듭제곱값으로 지정해야 한다. adb로 커널의 + *disc* 이미지를 수정하여 설정한다. 변수명은 + tcp_hash_size이다. tcp_hash_size + 변수값이 32비트이므로 disc 이미지를 수정할때 반드시 16비트 + 값을 기록하는 "w" 대신 32비트 값을 기록하는 + "W"를 사용해야 한다.

+ +

어떤 값을 고를까? ftp://ftp.cup.hp.com/dist/networking/tools/connhist의 + 결과를 보고, 시스템에 존재하는 TCP 연결 총개수를 살펴봐라. + 이 숫자를 해쉬테이블 크기로 나눈 값이 상당히 (10 이하) 작으면 + 좋다. HP의 SPECweb96 결과에서 일반적인 설정을 볼 수 있다. + 결과는 http://www.specbench.org/에 + 있다. HP-UX 시스템이 초당 1000번 SPECweb96 연결을 하는 경우 + TIME_WAIT가 60초라면 60,000개의 TCP "연결"을 + 추적한다는 뜻이다.

+ +

ftp://ftp.cup.hp.com/dist/networking/misc/listenq를 + 실행하여 시스템의 연결대기행렬 깊이를 알 수 있다.

+ +

PA-8000기반 시스템에서 아파치를 실행한다면, 아파치 + 실행파일이 큰 페이지크기를 사용하도록 "chatr"한다. 명령은 + "chatr +pi L <실행파일>"이다. 실행파일을 + 실행하는 GID에 MLOCK 권한이 반드시 필요하다. + MLOCK 부여에 대해서는 Setprivgrp(1m)를 + 참고하라. 수정후 Glance를 실행하여 서버의 메모리영역을 살펴보면 + 상당한 text 세그먼트가 잠겨있음을 확인할 수 있다.

+ +

다중프로세스 시스템에서 아파치를 실행한다면, 프로세스를 + 프로세스에 배정하는 mpctl()를 사용한 작은 + 프로그램을 작성해봐라. 단순한 pid % numcpu + 알고리즘으로도 충분할 것이다. 이 부분은 앞으로 소스코드에 + 포함될 수 있다.

+ +

FIN_WAIT_2 연결의 개수가 걱정스럽다면, + nettune을 사용하여 tcp_keepstart 값을 줄일 + 수 있다. 그러나 조심해야 한다 - 4분 보다 작게 설정하지 마라. + tcp_hash_size를 잘 설정하였다면, + FIN_WAIT_2 값이 커도 (심지어 기본값인 2시간도) + 문제없다 - 보통 성능에 큰 영향을 주지 않는다.

+ +

앞으로 소스코드에 포함될 부분이 더 있지만, 여기서 줄인다. + 관심이 있다면 메일을 주길 바란다.

+ +

그럼 이만,

+ +

rick jones

+ +

http://www.cup.hp.com/netperf/NetperfPage.html

+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/perf-hp.xml.ko b/docs/manual/platform/perf-hp.xml.ko index 70b61d75e0..bbcb16ac8e 100644 --- a/docs/manual/platform/perf-hp.xml.ko +++ b/docs/manual/platform/perf-hp.xml.ko @@ -1,7 +1,7 @@ - + +Microsoft Windows용 아파치 컴파일 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Platform Specific Notes

Microsoft Windows용 아파치 컴파일

+
+

가능한 언어:  en  | + ko 

+
+ + +

아파치를 컴파일하기 전에 주의할 점이 많다. 미리 Microsoft Windows에서 아파치 사용법을 + 참고하라.

+ +
+
+
top
+
+

요구사항

+ + + +

아파치를 컴파일하려면 다음이 정상적으로 설치되야 한다:

+ + + +
top
+
+

명령행에서 컴파일하기

+ + + +

먼저 적당한 디렉토리에 아파치 배포본 압축을 푼다. 명령행 + 프롬프트를 열고 그 디렉토리로 cd한다.

+ +

Makefile.win 파일에 아파치 makefile 명령이 + 있다. Windows NT에서 release와 debug + 컴파일하는 명령어는 각각 다음과 같다:

+ + 
+nmake /f Makefile.win _apacher
+
+nmake /f Makefile.win _apached
+
+ +

두 명령어 모두 아파치를 컴파일한다. 후자는 결과파일에 + 디버깅 정보를 포함하여 버그를 찾고 문제를 추적하기 쉽게 + 한다.

+ +
top
+
+

Developer Studio Workspace IDE에서 컴파일하기

+ + + +

VC++의 Visual Studio 개발 환경을 사용하여 아파치를 컴파일할 + 수도 있다. 과정을 쉽게 하려고 Visual Studio workspace + Apache.dsw를 제공한다. 이 workspace는 완전한 + 아파치 바이너리 배포본에 필요한 .dsp 프로젝트 + 목록을 담고있다. 또, 알맞은 순서로 컴파일하기위한 프로젝트간 + 의존성 정보도 포함한다.

+ +

Apache.dsw workspace를 열고 + InstallBin을 (Release나 + Debug 중 원하는 것을) Active Project로 선택한다. + InstallBin은 관련된 모든 프로젝트를 컴파일하고, + 컴파일된 실행파일과 dll을 옮기는 Makefile.win을 + 호출한다. InstallBin의 Settings, General 탭, + Build command line 항목을 수정하여 INSTDIR=을 + 변경할 수 있다. INSTDIR= 기본값은 + /Apache2 디렉토리이다. (설치하지않고) 테스트로 + 컴파일만 해보려면 대신 BuildBin 프로젝트를 + 사용한다.

+ +

.dsp 프로젝트 파일은 Visual C++ 6.0 형식이다. + Visual C++ 5.0 (97)에서도 이 파일을 사용할 수 있다. Visual + C++ 7.0 (.net)은 Apache.dsw와 .dsp + 파일들을 Apache.sln과 .msproj + 파일들로 변환한다. .dsp 소스파일을 수정하면 + 반드시 .msproj 파일로 다시 변환하라! 그냥 VC++ + 7.0 IDE에서 Apache.dsw를 다시 열기만 하면 된다.

+ +

또, Visual C++ 7.0 (.net) 사용자는 Build 메뉴, Configuration + Manager 대화창에서 Debug와 Release의 + abs, mod_ssl, mod_deflate + Solution modules 선택을 해제해야 한다. srclib에 + openssl이나 zlib 디렉토리가 있는 + 경우에만 nmake를 실행하거나 (이 모듈을 명시적으로 + 컴파일하는) IDE BinBuild 대상을 사용하여 모듈을 + 컴파일 할 수 있다.

+ +

Export한 .mak 파일들이 혼란스럽지만, Visual + C++ 5.0 사용자가 mod_ssl, abs (SSL을 지원하는 + ab), mod_deflate를 컴파일할때 필요하다. + VC++ 7.0 (.net) 사용자에게도 binenv 보다 + nmake를 사용하면 컴파일이 더 빠르다. VC++ 5.0이나 + 6.0 IDE에서 전체 프로젝트를 컴파일하고, Project 메뉴의 Export + for all makefiles를 사용하라. 동적으로 자동 생성하는 대상을 + 모두 컴파일하고 올바른 의존성 정보를 얻기위해서는 먼저 + 프로젝트를 컴파일해야 한다. 다음 명령어를 사용하여 경로를 + 수정하면 어떤 경로에서도 컴파일할 수 있다:

+ +

+ perl srclib\apr\build\fixwin32mak.pl +

+ +

httpd 소스 최상위 디렉토리에서 + 명령어를 실행해야 한다. 현재 디렉토리와 하위디렉토리에 있는 + 모든 .mak와 .dep 프로젝트파일을 + 수정하고, .dsp를 고려하여 파일시간을 수정한다.

+ +

프로젝트파일을 다듬어서 패치를 보낸다면, 프로젝트파일을 + Visual Studio 6.0 형식으로 만들어야 한다. 변경은 간단하고, + VC++ 5.0에서 7.0까지 모든 환경에서 인식하는 최소한의 컴파일 + 옵션과 링커 옵션을 사용해야 한다.

+ +
top
+
+

프로젝트 구성요소

+ + + +

Apache.dsw workspace와 makefile.win + nmake 스크립트는 다음 순서대로 아파치 서버 + .dsp 프로젝트를 컴파일한다:

+ +
    +
  1. srclib\apr\apr.dsp
    2. + +
  2. srclib\apr\libapr.dsp
    3. + +
  3. srclib\apr-util\uri\gen_uri_delims.dsp
    4. + +
  4. srclib\apr-util\xml\expat\lib\xml.dsp
    5. + +
  5. srclib\apr-util\aprutil.dsp
    6. + +
  6. srclib\apr-util\libaprutil.dsp
    7. + +
  7. srclib\pcre\dftables.dsp
    8. + +
  8. srclib\pcre\pcre.dsp
    9. + +
  9. srclib\pcre\pcreposix.dsp
    10. + +
  10. server\gen_test_char.dsp
    11. + +
  11. libhttpd.dsp
    12. + +
  12. Apache.dsp
    13. +
+ +

또, modules\ 하위디렉토리 아래 대부분의 + 모듈에는 프로젝트파일이 있다.

+ +

support\ 디렉토리에는 아파치를 실행하는데 + 필요하지는 않지만, 관리자가 아파치를 검사하거나 암호파일과 + 로그파일을 관리하는데 사용할 추가 프로그램들의 프로젝트파일이 + 있다. Windows 전용 지원 프로그램은 support\win32\ + 디렉토리에 따로 있다.

+ +
    +
  1. support\ab.dsp
    2. + +
  2. support\htdigest.dsp
    3. + +
  3. support\htpasswd.dsp
    4. + +
  4. support\logresolve.dsp
    5. + +
  5. support\rotatelogs.dsp
    6. + +
  6. support\win32\ApacheMonitor.dsp
    7. + +
  7. support\win32\wintty.dsp
    8. +
+ +

아파치를 컴파일하면 server root 디렉토리에 설치해야 한다. + 기본값은 같은 디스크의 \Apache2 디렉토리이다.

+ +

컴파일하고 모든 파일을 원하는 폴더 dir에 자동으로 + 설치하려면 다음 nmake 명령어중 하나를 사용한다:

+ + 
+nmake /f Makefile.win installr INSTDIR=dir
+
+nmake /f Makefile.win installd INSTDIR=dir
+
+ +

INSTDIR의 dir 아규먼트는 설치디렉토리를 + 뜻한다. 생락하면 \Apache2에 아파치를 설치한다.

+ +

다음과 같이 설치한다:

+ + + +

개발중인 아파치 버전을 컴파일할때 경고

+ + + +
.dsp 파일은 release마다 + 새로 만들어진다. 개발자의 시간낭비를 막기위해 + .mak 파일은 새로 만들지 않는다. 그러므로 + NMAKE 명령어를 사용하여 새로운 .dsp + 프로젝트파일을 컴파일할 수 없다. 프로젝트에서 직접 모든 + .mak 파일을 export해야 한다. Microsoft Developer + Studio 환경에서 컴파일한다면 이 작업이 필요없다.
+ +
또, makefile을 export하기 전에 BuildBin + 프로젝트를 (혹은 _apacher나 _apached + 명령행 대상) 컴파일하면 매우 도움이 된다. 컴파일중에 많은 + 파일이 자동으로 만들어진다. 전체를 컴파일해야만 정상적으로 + 컴파일할때 필요한 의존파일을 모두 만든다.
+ +

배포용 .mak 파일을 만드려면 항상 + .mak (혹은 .dep)에서 Platform + SDK 등의 의존성을 점검하라. + DevStudio\SharedIDE\bin\ (VC5)나 + DevStudio\Common\MSDev98\bin\ (VC6) 디렉토리에는 + 모든 예외 목록이 담긴 sysincl.dat 파일이 + 있다. 이 파일에 의존성 정보를 추가한다 + (sys/time.h와 sys\time.h와 같이, + 경로는 슬래쉬를 사용한 것과 백슬래쉬를 사용한 것 모두를 + 추가한다). 배포할 .mak 파일에 현재 컴퓨터에만 + 해당하는 설치경로가 있다면 컴파일이 완전히 실패한다. + 그러므로 srclib/apr/build/fixwin32mak.pl을 + 실행해하여 .mak 파일에 있는 절대경로를 없애야 + 한다.

+ + + +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/win_compiling.xml.ko b/docs/manual/platform/win_compiling.xml.ko index 588ee5ada7..56f04f1d65 100644 --- a/docs/manual/platform/win_compiling.xml.ko +++ b/docs/manual/platform/win_compiling.xml.ko @@ -1,7 +1,7 @@ - + +Microsoft Windows에서 아파치 사용법 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Platform Specific Notes

Microsoft Windows에서 아파치 사용법

+
+

가능한 언어:  en  | + ko 

+
+ + +

이 문서는 Microsoft Windows에서 아파치 2.0을 설치, 설정, + 실행하는 방법을 설명한다. 잘못된 부분이 있거나 다른 방법으로 + 도움을 주려면, 버그 보고 + 페이지를 사용하길 바란다.

+ +

이 문서는 아파치 바이너리 배포본을 설치한다고 가정한다. + (아마도 개발 혹은 버그를 찾기위해) 직접 아파치를 컴파일하려면 + Microsoft Windows용 아파치 + 컴파일을 참고하라.

+ +

현재 Microsoft Windows 운영체제군의 버전 정책상 + 이 문서는 다음과 같이 구분한다:

+ + +
+
+
top
+
+

운영체제 요구조건

+ + +

아파치 2.0을 실행하기위한 기본 Windows 플래폼은 Windows + NT이다. 바이너리 설치프로그램은 Intel과 AMD와 같은 x86 개열 + 프로세서에서만 동작한다. 아파치는 Windows 9x에서 충분히 + 검사하지 않았기때문에 절대로 실제 서비스에 사용하지 않길 + 바란다. +

+ +

운영체제에 설치한 TCP/IP 네트워크가 동작해야 한다. Windows + 95에서 실행한다면, Winsock 2 업그레이드를 설치해야 한다. + Windows 95용 Winsock 2는 여기에서 + 다운받을 수 있다. +

+ +

Windows NT 4.0을 사용한다면 서비스팩 4의 TCP/IP 문제와 + Winsock 문제가 다음 서비스팩에서 해결되었기때문에, 서비스팩 + 6을 설치하길 적극 권한다.

+
top
+
+

Windows용 아파치 다운로드

+ + +

아파치 웹서버 http://httpd.apache.org/download.cgi에서 + 아파치 최신 버전에 대한 정보를 얻을 수 있다. 여기에는 최신 + 발표판과 알파 혹은 베타 테스트버전과, 아파치 웹서버를 다운로드할 + 수 있는 HTTP 미러와 FTP 미러 목록이 있다. 빠르고 안정하게 + 다운받으려면 가까운 미러를 사용하길 바란다.

+ +

Windows에 설치하려면 확장자가 .msi인 Windows용 + 아파치 버전을 다운받아야 한다. 이 파일은 막바로 실행할 수 + 있는 아파치를 저장한 Microsoft 설치파일이다. 따로 소스코드만 + 묶어둔 .zip 파일이 있다. Microsoft Visual C++ + (Visual Studio)을 사용하여 직접 아파치를 컴파일할 수도 있다.

+
top
+
+

Windows용 아파치 설치하기

+ + +

설치하려면 Microsoft Installer 1.2 이상 버전이 필요하다. + Windows 9x를 사용한다면 여기에서 + Microsoft Installer를 2.0 버전으로 업그레이드할 수 있고, + Windows NT 4.0과 2000을 사용한다면 여기에서 + 2.0 버전 업데이트를 구할 수 있다. Windows XP는 업데이트할 + 필요가 없다.

+ +

바이너리 설치파일로는 같은 컴퓨터에 서로 다른 아파치 + 2.0 버전을 설치할 수 없음을 주의하라. 그러나 1.3 + 버전과 2.0 버전은 같은 컴퓨터에 아무 문제없이 + 설치할 수 있다. 같은 컴퓨터에 두가지 다른 2.0 버전을 설치하려면 + 소스를 컴파일하여 아파치를 + 설치해야 한다.

+ +

위에서 다운받은 아파치 .msi 파일을 실행한다. + 설치할때 다음과 같은 것을 물어본다:

+ +
    +

  1. 네트워크 도메인 (Network Domain). + 등록된 서버의 DNS 도메인을 입력한다. 예를 들어, 서버의 + 전체 DNS 이름이 server.mydomain.net이라면 + 여기에 mydomain.net을 입력한다.

    2. + +

  2. 서버명 (Server Name). 서버의 전체 + DNS 이름. 위의 경우 여기에 server.mydomain.net을 + 입력한다.

    3. + +

  3. 관리자 전자우편 주소 (Administrator's Email + Address). 여기에 서버 관리자나 웹마스터의 전자우편 + 주소를 입력한다. 기본적으로 클라이언트에게 보내는 오류문에 + 이 주소를 기록한다.

    4. + +

  4. 사용자 대상 (For whom to install + Apache) 새로 설치하는 아파치가 80번 포트에서 + 요청을 기다리게 하려면 for All Users, on Port 80, + as a Service - Recommended (모든 사용자, 80번 포트, + service로 - 추천)를 선택한다. 아파치를 service로 실행한다 + (즉, 아파치는 서버에 로그인한 사람이 없어도 실행된다). + 개인적으로 테스트해보거나 이미 80번 포트를 사용하는 다른 + 웹서버가 있다면 only for the Current User, on Port + 8080, when started Manually (현재 사용자만, 8080번 + 포트, 직접 시작)를 선택한다.

    5. + +

  5. 설치 종류 (The installation type). + 모듈 개발에 필요한 소스코드와 라이브러리를 제외한 모든 + 것을 설치하려면 Typical을 선택한다. + Custom을 선택하면 설치할 내용을 지정할 수 + 있다. 전체 설치시 디스크에 빈 공간이 약 13 메가바이트 + 정도 필요하다. 이 수치는 웹사이트 크기를 제외한 + 것이다.

    6. + +

  6. 설치 장소 (Where to install). + 기본 경로는 C:\Program Files\Apache Group이고, + 이곳에 Apache2라는 디렉토리를 만든다.

    7. +
+ +

설치할 동안 아파치는 conf 하위디렉토리에 + 있는 파일들을 선택한 설치 디렉토리에 맞게 구성한다. 그러나 + 이 디렉토리에 설정파일이 이미 있다면 그대로 둔다. 대신, + 해당 파일의 새로운 복사본에 확장자 .default를 + 붙인다. 예를 들어, conf\httpd.conf가 이미 있다면 + conf\httpd.conf.default로 이름을 변경한다. + 설치후 .default 파일의 설정을 직접 살펴보고, + 필요하다면 기존 설정파일을 수정해야 한다.

+ +

또, 이미 htdocs\index.html이라는 파일이 + 있다면 그대로 둔다 (index.html.default라고 + 복사하지도 않는다). 즉, 기존에 아파치가 설치되있더라도 안전하게 + 아파치를 새로 설치할 수 있다. 물론 설치하기 전에 서버를 + 중단하고, 설치후 새로운 서버를 시작해야 한다.

+ +

아파치 설치후 필요하다면 conf 하위디렉토리에 + 있는 설정파일을 수정해야 한다. 파일은 아파치를 설치한 디렉토리의 + htdocs 하위디렉토리에 있는 문서를 서비스하도록 + 설정되있다. 실제로 아파치를 사용하기 전에 설정해야 할 옵션이 + 많다. 그러나 빨리 실행해볼 수 있도록 기본 설정파일로도 동작한다.

+
top
+
+

Windows용 아파치 설정하기

+ + +

아파치는 conf 하위디렉토리에 있는 파일로 + 설정한다. 이 파일은 유닉스용과 같지만, Windows용 아파치 + 특유의 지시어가 몇개 있다. 사용가능한 모든 지시어를 보려면 + 지시어 목록을 참고하라.

+ +

Windows용 아파치의 주된 차이점은:

+ + +
top
+
+

아파치를 Service로 실행하기

+ + +

Windows NT에서는 아파치를 service로 실행할 수 있다. Windows + 9x에는 매우 실험적인 방법으로 비슷한 기능을 지원한다.

+ +

설치시 자동으로 아파치를 service로 설치할 수 있다. "모든 + 사용자"를 선택하면, 아파치 service가 만들어진다. "현재 + 사용자만"을 선택하더라도 설치후 직접 아파치를 service로 + 등록할 수 있다. service를 설치하려면 Administrators 그룹의 + 구성원이어야 한다.

+ +

아파치에는 Apache Service Monitor라는 도구가 있다. 이 + 도구를 사용하면 네트웍에 있는 다른 컴퓨터에 설치된 아파치 + 상태도 확인하고 관리할 수 있다. monitor로 아파치 service를 + 관리하려면 먼저 service를 (설치시 자동으로 혹은 직접) 설치해야 + 한다. +

+ +

아파치 bin 하위디렉토리에서 명령행 프롬프트에 + 다음과 같이 입력하면 아파치를 Windows NT service로 설치한다:

+ +

+ apache -k install +

+ +

설치할 service 이름을 지정하고 싶다면 다음 명령어를 사용한다. + 컴퓨터에 아파치가 여러개 설치되있다면 이름을 다르게 주어야 + 한다.

+ +

+ apache -k install -n "MyServiceName" +

+ +

service가 사용할 설정파일을 직접 지정하려면 다음과 같이 + 한다:

+ +

+ apache -k install -n "MyServiceName" -f "c:\files\my.conf" +

+ +

-k install 외에 다른 파라미터를 사용하지 + 않으면, service 이름은 Apache2가 되고 설정파일은 + conf\httpd.conf가 된다. +

+ +

아파치 service를 제거하기 쉽다. 간단히:

+ +

+ apache -k uninstall +

+ +

다음과 같이 제거할 아파치 service를 지정할 수 있다:

+ +

+ apache -k uninstall -n "MyServiceName" +

+ +

보통 아파치 service 시작, 재시작, 종료는 Apache Service + Monitor나 NET START Apache2, NET STOP + Apache2 같은 명령어 혹은 Windows 서비스 관리창에서 + 한다. 어떤 방법을 사용하든지 아파치 service를 시작하기 전에 + 설정파일을 검사해봐야 한다:

+ +

+ apache -n "MyServiceName" -t +

+ +

명령행 옵션으로도 아파치 service를 조정할 수 있다. 설치한 + 아파치 serivce를 시작하려면:

+ +

+ apache -k start +

+ +

명령행 옵션으로 아파치 service를 종료하려면:

+ +

+ apache -k stop +

+ +

혹은

+ +

+ apache -k shutdown +

+ +

실행중인 service를 재시작하여 설정파일을 다시 읽도록 + 할 수 있다:

+ +

+ apache -k restart +

+ +

기본적으로 모든 아파치 service는 시스템 사용자 + (LocalSystem 계정) 권한으로 실행하도록 등록된다. + Windows 보안구조상 LocalSystem 계정은 파일시스템, + named pipes, DCOM, secure RPC 등 어떤 방법을 사용하든지 + 네트웍에 접근할 수 없다. 그러나 해당 컴퓨터에서는 많은 권한을 + 가진다. +

+ +
LocalSystem 계정에게 + 네트웍 권한을 절대로 주지 마라! 아파치가 네트웍 자원에 접근해야 + 한다면, 아래에서 설명하는 방법으로 아파치를 위한 별도의 + 계정을 만들어라.
+ +

아파치 service를 실행하기위한 별도의 계정을 만들 수도 + 있다. 특히 아파치가 네트웍 자원에 접근해야 한다면 이 방법을 + 강력히 권한다.

+ +
    +
  1. 일반 도메인 사용자 계정을 만들고 암호를 기억하라.
    2. + +
  2. 새로 만든 계정에 서비스로 로그온와 + 운영 체제의 일부로 활동 권한을 + 부여한다. Windows NT 4.0에서는 User Manager for Domains에서 + 권한을 부여할 수 있고, Windows 2000과 XP에서는 아마도 + "그룹 정책"을 사용해야 한다. "로컬 보안 설정" MMC + 스냅인에서 직접 설정해줄 수도 있다. +
    3. + +
  3. 새로 만든 계정이 Users 그룹에 속하는지 확인한다.
    4. + +
  4. 모든 문서와 스크립트 폴더에 (예를 들어 + htdocs와 cgi-bin) 대해 읽기 및 + 실행 (RX) 권한을 부여한다.
    5. + +
  5. 아파치 logs 디렉토리에 수정 (RWXD) 권한을 + 부여한다.
    6. + +
  6. Apache.exe 실행파일에 읽기 및 실행 (RX) + 권한을 부여한다.
    7. +
+ +
아파치 service를 실행하는 사용자에게 최소한 수정 (RWXD) + 권한이 필요한 logs 하위디렉토리를 제외하고 + Apache2 디렉토리 전체에 읽기 및 실행 (RX) 권한을 부여하는 + 것이 좋다.
+ +

계정에 "로컬 로그온"과 "서비스로 로그온" 권한이 있다면, + 그 계정으로 로그온하여 계정이 스크립트를 실행하고 웹페이지를 + 읽으며 콘솔창에서 아파치를 시작할 수 있는지 검사해볼 수 + 있다. 여기서 문제가 없다면 아파치를 service로 실행해도 문제가 + 없다.

+ +
Error code 2186은 아파치가 필요한 + 네트웍 자원에 접근할 수 없다는 말로 service의 "로그온" + 설정을 확인하라. 또, 아파치를 실행하는 계정의 권한을 + 살펴봐라.
+ +

아파치를 service로 실행하면 Windows Service Control + Manager에서 오류문을 볼 수 있다. 예를 들어, 제어판에서 + "서비스"를 사용하여 아파치를 시작하는 경우 다음과 같은 문구가 + 나올 수 있다:

+ +

+ Could not start the Apache2 service on \\COMPUTER
+ Error 1067; The process terminated unexpectedly. +

+ +

아파치 service를 시작할때 문제가 있으면 일반적인 이런 + 오류가 나온다. 실제 어디가 문제인지 알려면 아파치를 콘솔 + 프로그램으로 실행해보라.

+ +

Windows 9x에서 아파치는 Windows NT의 service와 비슷한 + 방법을 지원한다. 그러나 매우 실험적인 기능이다. + 실제 서비스에 사용할만큼 안정적이지 않고 앞으로 개선될지 + 보장할 수도 없다. 위험하므로 혹시나 사용한다면 주의해서 + 사용해야 한다!

+ +

두가지 service의 중요한 차이점은 다음과 같다:

+ + + +

아파치가 콘솔 프로그램으로 동작함을 확인하였다면 Windows + NT에서와 같은 명령어로 가상 service를 설치, 조절, 제거할 + 수 있다. 또, Apache Service Monitor를 사용하여 Windows 9x + 가상 service를 관리할 수 있다.

+ +
top
+
+

아파치를 콘솔 프로그램으로 실행하기

+ + +

일반적으로 아파치를 service로 실행하길 권한다. 그러나 + 명령행에서 실행하는게 편한 경우가 있다 (Windows 9x에서는 + service를 안정적으로 지원하지 않기때문에 명령행에서 아파치를 + 실행하는 방법을 권한다).

+ +

아파치를 콘솔 프로그램으로 실행하려면, 명령행에서 다음 + 명령어를 사용한다:

+ +

+ apache +

+ +

아파치는 Control-C를 눌러서 정지할 때까지 실행된다.

+ +

또, 시작 메뉴 --> 프로그램 --> Apache HTTP + Server 2.0.xx --> Control Apache Server에 설치된 + Start Apache in Console 바로가기로 아파치를 실행할 수 있다. + 바로가기를 실행하면 콘솔창을 열고 그 안에서 아파치를 실행한다. + 아파치를 service로 설치하지 않았다면, 아파치를 실행하는 + 콘솔창에서 Control-C를 눌러 아파치를 중단할때까지 창이 떠있다. + 이 경우 서버는 몇초안에 종료한다. 그러나, 아파치를 service로 + 설치하였다면 바로가기는 service를 시작한다. 아파치 service가 + 이미 실행중이라면 바로가기는 아무일도 하지 않는다.

+ +

다른 콘솔창을 열고 다음과 같이 입력하여 실행중인 아파치를 + 종료할 수 있다:

+ +

+ apache -k shutdown +

+ +

이 방법은 아파치가 현재 작업을 마치고 점잖게 종료할 수 + 있기때문에 Control-C 보다 낫다.

+ +

또, 아파치를 재시작할 수 있다. 이 경우 설정파일을 다시 + 읽는다. 진행중인 작업을 중간에 끊지않고 완료한다. 아파치를 + 재시작하려면:

+ +

+ apache -k restart +

+ +
유닉스용 아파치에 익숙한 사람을 위해: 이 명령어는 + kill -TERM pid나 kill -USR1 + pid의 Windows판이다. 명령행 옵션 + -k는 유닉스 kill 명령어 이름을 + 본따 지었다.
+ +

아파치 콘솔창이 즉시 혹은 시작후 갑자기 닫치면 시작 메뉴 + --> 프로그램의 명령 프롬프트를 실행한다. 아파치를 설치한 + 폴더로 가서 apache 명령어를 실행해보고 발생한 + 오류문을 살펴본다. 그리고 logs 폴더로 가서, 설정파일이 + 잘못되었는지 error.log 파일을 살펴본다. 아파치를 + 설치할때 기본값을 사용했다면 다음과 같다:

+ +

+ c:
+ cd "\Program Files\Apache Group\Apache2\bin"
+ apache +

+ +

아파치가 정지할 때까지 기다리거나 Control-C를 누른다. + 그리고 다음과 같이 입력한다:

+ +

+ cd ..\logs
+ more < error.log +

+ +

아파치를 다룰때 아파치가 어떻게 설정파일을 찾는지 아는 + 것이 중요하다. 두가지 방법으로 명령행에서 설정파일을 지정할 + 수 있다:

+ + + +

두 경우 모두 설정파일이 적절한 ServerRoot를 지정해야 한다.

+ +

-f나 -n으로 설정파일을 지정하지 + 않으면, 아파치는 conf\httpd.conf와 같이 서버에 + 컴파일된 파일명을 사용한다. 이 기본 경로는 설치 디렉토리에 + 상대적이다. 다음과 같이 -V 옵션으로 아파치를 + 실행하면 SERVER_CONFIG_FILE이란 항목에서 서버가 + 사용할 설정파일을 알 수 있다:

+ +

+ apache -V +

+ +

아파치는 다음 순서대로 ServerRoot를 찾는다:

+ +
    +
  1. -C 명령행 옵션에 사용한 ServerRoot 지시어.
    2. + +
  2. -d 명령행 옵션.
    3. + +
  3. 현재 작업 디렉토리.
    4. + +
  4. 바이너리 설치를 했다면 설치할때 만든 registry 항목.
    5. + +
  5. 서버에 컴파일된 server root. 기본값은 + /apache이고, apache -V를 실행하면 + HTTPD_ROOT라는 항목에서 확인할 수 있다.
    6. +
+ +

설치할때 윈도우즈 레지스트리에 버전 특유의 레지스트리 + 키를 만든다. 키의 위치는 설치 종류에 따라 다르다. install + Apache for all users를 선택하였다면 + HKEY_LOCAL_MACHINE 아래에 다음과 같은 키를 + 만든다 (물론 버전번호는 아파치 버전마다 다르다): +

+ +

+ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Group\Apache\2.0.43 +

+ +

"모든 사용자"를 대상으로 아파치를 설치하였다면 + HKEY_CURRENT_USER 아래 키가 생긴다. 내용은 + 현재 로그온한 사용자에 따라 다르다:

+ +

+ HKEY_CURRENT_USER\SOFTWARE\Apache Group\Apache\2.0.43 +

+ +

키 이름이 서버에 컴파일되기때문에 현재 버전을 건드리지않고 + 새로운 버전을 설치하여 테스트해볼 수 있다. 물론 새 버전을 + 다른 버전과 같은 디렉토리에 설치하지않도록 주의해야 한다.

+ +

바이너리 설치를 하지 않은 경우 아파치는 레지스트리 키가 + 없다고 불평할 수 있다. 서버가 다른 방법으로 설정파일을 찾을 + 수 있다면 이 경고를 무시해도 된다.

+ +

키의 값은 ServerRoot + 디렉토리이며, 이 디렉토리에 conf라는 하위디렉토리가 + 있다. 아파치를 시작하면 이 하위디렉토리에서 + httpd.conf 파일을 읽는다. 이 파일에 나오는 + ServerRoot 지시어가 + 레지스트리 키에 나온 디렉토리와 다르다면, 아파치는 레지스트리에서 + 얻은 값을 무시하고 앞으로 설정파일에 나온 디렉토리를 사용한다. + 아파치 디렉토리나 설정파일을 다른 장소로 복사하면 반드시 + httpd.conf 파일에 있는 ServerRoot 지시어를 그 위치로 + 수정하라.

+ +
top
+
+

정상적으로 설치되었는지 검사하기

+ + +

(콘솔창이나 service를 통해) 아파치를 시작하면 (설정파일의 + Listen 지시어를 + 수정하거나 아파치를 "현재 사용자만" 대상으로 설치하지 않는 + 경우) 80번 포트를 기다린다. 브라우저를 시작하고 URL을 입력하여 + 서버의 기본 페이지에 접근하다:

+ +

+ http://localhost/ +

+ +

아파치는 아파치 설명서 링크가 있는 환영페이지를 보여줘야 + 한다. 아무 일도 일어나지 않거나 오류가 나오면, logs + 하위디렉토리에 있는 error.log 파일을 살펴봐라. + 호스트가 네트웍에 연결되있지 않거나 DNS (Domain Name Service) + 설정에 문제가 있다면 다음 URL을 사용해야 한다:

+ +

+ http://127.0.0.1/ +

+ +

기본 설치가 동작하면 conf 하위디렉토리에 + 있는 파일을 적절히 설정한다. 또, Windows NT 아파치 service + 설정을 수정한 경우 먼저 명령행에서 아파치를 시작하여 오류가 + 발생하지않는지 확인해야 한다.

+ +

아파치가 다른 TCP/IP 프로그램과 같은 포트를 공유할 수 + 없기때문에 아파치를 시작하기 전에 다른 + 서비스를 중단, 제거, 재설정해야 할지도 모른다. 다른 웹서버나 + 특정 방화벽 서버스와 충돌할 수 있다. +

+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/platform/windows.xml.ko b/docs/manual/platform/windows.xml.ko index 19c62c1a35..f06f791bd6 100644 --- a/docs/manual/platform/windows.xml.ko +++ b/docs/manual/platform/windows.xml.ko @@ -1,7 +1,7 @@ - + +ab - 아파치 웹서버 성능검사 도구 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

ab - 아파치 웹서버 성능검사 도구

+
+

가능한 언어:  en  | + ko 

+
+ +

ab는 아파치 하이퍼텍스트 전송 프로토콜 (HTTP) + 서버의 성능을 검사하는(benchmarking) 도구이다. 현재 아파치가 + 어떻게 동작하는지 알려준다. 특히 아파치가 현재 초당 몇개의 + 요청을 서비스하는지 알려준다.

+
+

참고

+
top
+
+

개요

+

ab + [ -A auth-username:password ] + [ -c concurrency ] + [ -C cookie-name=value ] + [ -d ] + [ -e csv-file ] + [ -g gnuplot-file ] + [ -h ] + [ -H custom-header ] + [ -i ] + [ -k ] + [ -n requests ] + [ -p POST-file ] + [ -P proxy-auth-username:password ] + [ -q ] + [ -s ] + [ -S ] + [ -t timelimit ] + [ -T content-type ] + [ -v verbosity] + [ -V ] + [ -w ] + [ -x <table>-attributes ] + [ -X proxy[:port] ] + [ -y <tr>-attributes ] + [ -z <td>-attributes ] + [http://]hostname[:port]/path

+
top
+
+

옵션

+
+
-A auth-username:password
+
서버에게 BASIC Authentication 정보를 제공한다. + :으로 구분한 사용자명과 암호를 base64 인코딩하여 + 전송한다. 서버가 정보를 요구하는지 (예를 들어, + 401 인증 필요를 보내는지) 관계없이 문자열을 전송한다.
+ +
-c concurrency
+
동시에 요청하는 요청수. 기본적으로 한번에 한 요청만을 + 보낸다.
+ +
-C cookie-name=value
+
요청에 Cookie: 헤더를 추가한다. 아규먼트는 + 보통 name=value와 같은 + 쌍이다. 이 옵션은 여러번 사용할 수 있다.
+ +
-d
+
"percentage served within XX [ms] table"을 출력하지 + 않는다. (호환성을 위해).
+ +
-e csv-file
+
요청을 처리하는데 걸린 (밀리초 단위) 시간들의 (1%에서 + 100%) 누적백분율을 쉼표로 구분한 형식(CSV)으로 출력한다. + 결과를 이미 '정리'하였기때문에 'gnuplot' 파일보다 보통 더 + 유용하다.
+ +
-g gnuplot-file
+
측정한 모든 값을 'gnuplot' 혹은 TSV (Tab separate values, + 탭으로 구분한 값) 파일에 기록한다. Gnuplot, IDL, Mathematica, + Igor, 심지어 Excell 같은 프로그램에서도 이런 파일을 쉽게 + 읽을 수 있다. 파일의 첫번째 줄에 항목이름이 나온다.
+ +
-h
+
사용법을 출력한다.
+ +
-H custom-header
+
요청에 헤더를 추가한다. 아규먼트는 보통 콜론으로 구분한 + 쌍인 (예를 들어, + "Accept-Encoding: zip/zop;8bit") 유효한 + 헤더줄이다.
+ +
-i
+
GET 대신 HEAD 요청을 한다.
+ +
-k
+
HTTP KeepAlive 기능을 사용한다. 예를 들어, + 한 HTTP 세션에서 여러 요청을 한다. 기본적으로 KeepAlive를 + 사용하지 않는다.
+ +
-n requests
+
성능을 검사하기위해 보내는 요청수. 기본값으로 요청을 + 한번만 보내기때문에 일반적인 성능검사 결과를 얻을 수 없다.
+ +
-p POST-file
+
POST 자료 파일.
+ +
-P proxy-auth-username:password
+
프록시를 통해 BASIC Authentication 정보를 제공한다. + :로 구분한 사용자명과 암호를 base64 인코딩하여 + 전송한다. 프록시가 정보를 요구하는지 (예를 들어, + 401 인증 필요를 보내는지) 관계없이 문자열을 전송한다.
+ +
-q
+
150개 이상 요청을 보낼때 ab는 10% 혹은 + 매 100 요청당 표준오류에 진행상황을 출력한다. + -q 옵션은 이 문구를 출력하지 않는다.
+ +
-s
+
기능을 추가하여 컴파일하였다면 (ab -h로 + 확인할 수 있다) http 프로토콜 대신 SSL을 사용한 + https 프로토콜을 사용한다. 이 기능은 실험적이고 + 매우 기초적이다. 아마도 사용을 꺼려할 것이다.
+ +
-S
+
중간값과 표준편차를 출력하지 않고, 평균과 중간값의 차이가 + 표준편차보다 크더라도 경고/오류를 출력하지 않는다. + 최소/평균/최대 값을 출력한다. (호환성을 위해).
+ +
-t timelimit
+
성능을 검사하는 최대 초단위 시간. 내부적으로 + -n 50000을 가정한다. 정해진 시간동안 서버 성능을 + 검사할때 사용한다. 기본적으로 시간제한 없이 검사한다.
+ +
-T content-type
+
POST 자료의 Content-type 헤더.
+ +
-v verbosity
+
출력의 자세함 수준을 지정한다. 4 이상이면 + 헤더에 대한 정보를, 3 이상이면 (404, 202, 등) + 응답코드를, 2 이상이면 경고(warning)와 + 정보(info)를 출력한다.
+ +
-V
+
버전을 출력하고 종료한다.
+ +
-w
+
결과를 HTML 표로 출력한다. 기본적으로 표를 흰 배경에 + 두 열로 작성한다.
+ +
-x <table>-attributes
+
<table>의 속성으로 사용할 문자열. + 속성을 <table 여기에 > + 추가한다.
+ +
-X proxy[:port]
+
프록시 서버를 사용하여 요청한다.
+ +
-y <tr>-attributes
+
<tr>의 속성으로 사용할 문자열.
+ +
-z <td>-attributes
+
<td>의 속성으로 사용할 문자열.
+
+
top
+
+

버그

+

정적으로 길이가 고정된 버퍼를 많이 사용한다. 명령행 + 아규먼트, 서버의 응답 헤더, 다른 외부 입력들을 같이 + 읽어들이면서 문제가 발생할 수 있다.

+ +

이 프로그램은 HTTP/1.x를 완전히 구현하지 않는다; 단지 + '기대하는' 형식의 응답만을 받는다. strstr(3)을 + 매우 많이 사용기때문에 속도가 문제가 될 수 있다; 즉, + 서버 성능보다는 ab 성능을 측정하게 될 수도 + 있다.

+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/ab.xml.ko b/docs/manual/programs/ab.xml.ko index f040856824..09dda2dba2 100644 --- a/docs/manual/programs/ab.xml.ko +++ b/docs/manual/programs/ab.xml.ko @@ -1,7 +1,7 @@ - + +apachectl - 아파치 웹서버 조절 인터페이스 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

apachectl - 아파치 웹서버 조절 인터페이스

+
+

가능한 언어:  en  | + ko 

+
+ +

apachectl은 아파치 하이퍼텍스트 전송 + 프로토콜 (HTTP) 서버의 앞단이다. 이 프로그램은 관리자가 + 아파치 httpd 데몬을 조정하도록 + 돕는다.

+ +

apachectl 스크립트는 두가지 방법으로 실행한다. + 첫번째 방법은 httpd을 부르는 간단한 스크립트 + 역할을 하여, 필요한 환경변수를 설정하고 받은 명령행 아규먼트를 + 가지고 httpd를 실행한다. 두번째 방법은 + apachectl를 SysV init 스크립트로 사용하여, + start, restart, stop + 같은 한단어 아규먼트를 받아서 httpd에게 + 적절한 신호를 보낸다.

+ +

아파치를 일반적인 경로에 설치하지 않았다면, 적절한 + httpd 경로로 apachectl 스크립트를 + 수정해야 한다. 또, httpd 명령행 아규먼트를 + 추가로 지정할 수 있다. 자세한 내용은 스크립트의 주석을 + 참고하라.

+ +

apachectl 스크립트는 성공시 종료코드 0을, + 오류시 >0을 반환한다. 자세한 내용은 스크립트의 주석을 + 참고하라.

+
+

참고

+
top
+
+

개요

+ +

간단한 실행 스크립트로 동작하면, apachectl은 +httpd 실행파일의 모든 아규먼트를 받는다.

+ +

apachectl [ httpd-argument ]

+ +

SysV init 방식으로 동작하면, apachectl은 아래서 +설명할 간단한 한단어 명령어를 받는다.

+ +

apachectl command

+ +
top
+
+

옵션

+ +

여기서는 SysV init-식 옵션만 설명한다. 다른 옵션은 httpd manpage에서 설명한다.

+ +
+ +
start
+ +
아파치 httpd 데몬을 시작한다. 이미 실행중이라면 +오류를 낸다. apachectl -k start와 같다.
+ +
stop
+ +
아파치 httpd 데몬을 중단한다. apachectl +-k stop과 같다.
+ +
restart
+ +
아파치 httpd 데몬을 재시작한다. 데몬이 실행중이 +아니라면, 시작한다. 데몬이 재시작시 실패하지 않음을 확인하기위해 +재시작 전에 자동으로 configtest 명령과 같이 설정파일을 +검사한다. apachectl -k restart와 같다.
+ +
fullstatus
+ +
mod_status의 모든 상태 정보를 출력한다. +이 명령을 사용하기위해서는 서버가 mod_status를 +사용하고, 시스템에 lynx 같은 문자기반 브라우저가 +필요하다. 상태 정보에 접근하는 URL은 스크립트의 +STATUSURL 변수를 수정하여 설정할 수 있다.
+ +
status
+ +
간단한 상태 정보를 출력한다. fullstatus 옵션과 +비슷하지만, 현재 서비스중인 요청 목록을 출력하지 않는다.
+ +
graceful
+ +
아파치 httpd 데몬을 점잖게(gracefully) 재시작한다. +데몬이 실행중이 아니라면, 시작한다. 일반적인 재시작과 달리 현재 +열려있는 연결을 끊지않는다. 또, 이전 로그파일을 즉시 닫지 않는다. +즉, 로그순환 스크립트에서 이 명령을 사용한다면, 이전 로그파일을 +처리하기전에 로그파일을 닫혔음을 보장하기위해 상당히 기다려야 +한다. 아파치가 재시작시 실패하지 않음을 확인하기위해 재시작 +전에 자동으로 configtest 명령과 같이 설정파일을 +검사한다. apachectl -k graceful과 같다.
+ +
configtest
+ +
설정파일의 문법을 검사한다. 설정파일을 읽고 Syntax +Ok 혹은 특정 설정오류에 대한 자세한 정보를 알려준다. +apachectl -t와 같다.
+ +
+ +

아래 옵션을 사용할 수 있지만, 앞으로 사라질 것이다.

+ +
+ +
startssl
+ +
apachectl -k start -DSSL과 같다. 우리는 직접 +앞의 명령어를 사용하거나 항상 SSL을 사용하도록 +httpd.conf에서 <IfDefine> 섹션을 제거하길 권한다.
+ +
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/apachectl.xml.ko b/docs/manual/programs/apachectl.xml.ko index 1d60e39726..e4a652cfd3 100644 --- a/docs/manual/programs/apachectl.xml.ko +++ b/docs/manual/programs/apachectl.xml.ko @@ -1,7 +1,7 @@ - + +apxs - APache eXtenSion 도구 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

apxs - APache eXtenSion 도구

+
+

가능한 언어:  en  | + ko 

+
+ +

apxs는 아파치 하이퍼텍스트 전송 프로토콜 + (HTTP) 서버의 확장모듈을 컴파일하고 설치하는 도구이다. 이 + 도구는 여러 소스와 오브젝트파일을 가지고, + mod_so의 LoadModule 지시어로 실행중에 + 아파치 서버로 읽어들일 수 있는 동적공유객체(DSO)를 만든다.

+ +

그래서 이런 확장방식을 사용하려면 플래폼이 DSO 기능을 + 지원하고 아파치 httpd 실행파일을 + mod_so 모듈과 같이 컴파일해야 한다. + apxs 도구는 이 조건이 만족하지않으면 실행하지 + 않는다. 직접 명령어를 실행하여 조건이 만족하는지 알아볼 + 수 있다

+ +

+ $ httpd -l +

+ +

목록에 mod_so 모듈이 나와야 한다. 조건을 + 만족하면 apxs 도구로 DSO 모듈을 설치하여 + 아파치서버의 기능을 쉽게 확장할 수 있다:

+ +

+ $ apxs -i -a -c mod_foo.c
+ gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
+ ld -Bshareable -o mod_foo.so mod_foo.o
+ cp mod_foo.so /path/to/apache/modules/mod_foo.so
+ chmod 755 /path/to/apache/modules/mod_foo.so
+ [activating module `foo' in /path/to/apache/etc/httpd.conf]
+ $ apachectl restart
+ /path/to/apache/sbin/apachectl restart: httpd not running, trying to start
+ [Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
+ /path/to/apache/sbin/apachectl restart: httpd started
+ $ _ +

+ +

아규먼트 files에는 C 소스파일 (.c) 이나 + 오브젝트파일 (.o), 라이브러리모음 (.a)을 사용할 수 있다. + apxs 도구는 확장자를 보고 자동으로 C 소스파일은 + 컴파일하고, 오브젝트와 모음파일은 링크에만 사용한다. 그러나 + 컴파일한 오브젝트를 사용하려면 동적으로 읽어들일 수 있는 + 공유객체로 사용하기위해 반드시 오브젝트를 위치독립코드(PIC, + position independent code)로 컴파일해야 한다. GCC의 경우 + -fpic을 사용하면 된다. 다른 C 컴파일러는 설명서를 + 참고하거나 apxs가 오브젝트파일을 컴파일할때 + 사용하는 옵션을 참고하라.

+ +

아파치의 DSO 지원에 대한 더 자세한 내용은 + mod_so 문서를 참고하거나 + src/modules/standard/mod_so.c 소스파일을 읽어봐라.

+
+

참고

+
top
+
+

개요

+

apxs -g + [ -S name=value ] + -n modname

+ +

apxs -q + [ -S name=value ] + query ...

+ +

apxs -c + [ -S name=value ] + [ -o dsofile ] + [ -I incdir ] + [ -D name=value ] + [ -L libdir ] + [ -l libname ] + [ -Wc,compiler-flags ] + [ -Wl,linker-flags ] + files ...

+ +

apxs -i + [ -S name=value ] + [ -n modname ] + [ -a ] + [ -A ] + dso-file ...

+ +

apxs -e + [ -S name=value ] + [ -n modname ] + [ -a ] + [ -A ] + dso-file ...

+
top
+
+

옵션

+

공통 옵션

+
+
-n modname
+
-i (install)과 -g (template + generation) 옵션을 사용할때 직접 모듈명을 지정한다. 이 + 옵션을 사용하여 모듈명을 직접 지정한다. -g + 옵션을 사용한다면 이 옵션을 반드시 사용해야하고, + -i 옵션을 사용한다면 apxs 도구는 + 소스나 (마지막 시도로) 파일명을 가지고 이름을 추측한다.
+
+ + +

질의 옵션

+
+
-q
+
apxs의 설정값을 알아낸다. query에는 + 다음을 사용할 수 있다: CC, CFLAGS, + CFLAGS_SHLIB, INCLUDEDIR, + LD_SHLIB, LDFLAGS_SHLIB, + LIBEXECDIR, LIBS_SHLIB, + SBINDIR, SYSCONFDIR, TARGET. + +

설정을 직접 알아낼때 사용한다.

+

+ INC=-I`apxs -q INCLUDEDIR` +

+ +

예를 들어, 아파치 C 헤더파일을 직접 접근한다면 + Makefile에서 위와 같이 사용한다.

+
+ + +

설정 옵션

+
+
-S name=value
+
이 옵션은 위에서 설명한 apxs 설정을 변경한다.
+
+ + +

견본(template) 생성 옵션

+
+
-g
+
하위디렉토리 name을 만들고 (-n + 옵션 참고) 그곳에 파일 두개를 만든다: 한 파일은 + mod_name.c라는 견본 모듈소스파일로, + 자신의 모듈을 만들때 견본으로 사용하거나 apxs 기능을 + 시험해볼때 사용한다. 다른 파일은 이 모듈을 쉽게 컴파일하고 + 설치하기위한 Makefile이다.
+
+ + +

DSO 컴파일 옵션

+
+
-c
+
컴파일을 지시한다. 먼저 files에서 C + 소스파일들(.c)을 오브젝트파일(.o)로 컴파일하고, + files의 나머지 오브젝트파일들(.o과 .a)과 + 링크하여 동적공유객체 dsofile을 만든다. + -o 옵션을 사용하지않으면 files의 + 첫번째 파일명에서 이름을 추측하여 보통 + mod_name.so를 사용한다.
+ +
-o dsofile
+
생성할 동적공유객체 파일명을 직접 지정한다. 이름을 + 지정하지않고 files 목록에서 이름을 추측하지 + 못하면 마지막으로 mod_unknown.so를 이름으로 + 사용한다.
+ +
-D name=value
+
이 옵션을 컴파일 명령어로 직접 전달한다. + 컴파일때 자신의 define을 추가한다.
+ +
-I incdir
+
이 옵션을 컴파일 명령어로 직접 전달한다. + 컴파일때 include를 찾을 디렉토리를 추가한다.
+ +
-L libdir
+
이 옵션을 링커 명령어로 직접 전달한다. + 컴파일때 라이브러리를 찾을 디렉토리를 추가한다.
+ +
-l libname
+
이 옵션을 링커 명령어로 직접 전달한다. + 컴파일때 사용할 라이브러리를 추가한다.
+ +
-Wc,compiler-flags
+
이 옵션은 추가 옵션 compiler-flags를 + 컴파일 명령어로 전달한다. 컴파일러 특유의 옵션을 추가할때 + 사용한다.
+ +
-Wl,linker-flags
+
이 옵션은 추가 옵션 linker-flags를 + 링커 명령어로 전달한다. 링커 특유의 옵션을 추가할때 + 사용한다.
+
+ + +

DSO 설치과 설정 옵션

+ +
+
-i
+
설치를 지시한다. 여러 동적공유객체를 서버의 + modules 디렉토리에 설치한다.
+ +
-a
+
아파치 httpd.conf 설정파일에 적절한 + LoadModule 줄을 + 추가하거나 이미 있다면 활성화하여 모듈을 사용하도록 + 만든다.
+ +
-A
+
-a와 비슷하지만, LoadModule 지시어 앞에 + 우물정자(#)를 붙인다. 즉, 현재는 + 사용하지않지만 나중에 사용할 수 있도록 모듈을 준비한다.
+ +
-e
+
편집을 지시한다. -a 혹은 -A + 옵션과 같이 사용할 수 있으며, -i 명령과 + 비슷하지만 모듈을 설치하지않고 아파치 + httpd.conf 설정파일만 편집한다.
+
+ +
top
+
+

예제

+

아파치서버의 기능을 확장하는 mod_foo.c라는 + 아파치 모듈이 있다고 가정하자. 먼저 다음 명령어를 사용하여 + C 소스를 아파치 서버가 읽어들일 공유객체로 컴파일한다:

+ +

+ $ apxs -c mod_foo.c
+ gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
+ ld -Bshareable -o mod_foo.so mod_foo.o
+ $ _ +

+ +

그리고 이 공유객체를 읽어들이는 LoadModule 지시어를 아파치 + 설정에 추가한다. apxs는 자동으로 공유객체를 + "modules" 디렉토리에 설치하고 httpd.conf 파일을 + 알맞게 수정하여 간단히 작업을 마친다. 다음 같이 실행한다:

+ +

+ $ apxs -i -a mod_foo.c
+ cp mod_foo.so /path/to/apache/modules/mod_foo.so
+ chmod 755 /path/to/apache/modules/mod_foo.so
+ [activating module `foo' in /path/to/apache/etc/httpd.conf]
+ $ _ +

+ +

그러면 다음과 같은 줄을

+ +

+ LoadModule foo_module modules/mod_foo.so +

+ +

설정파일에 없다면 추가한다. 이 설정을 기본적으로 사용하지 + 않는다면 -A 옵션을 사용한다. 즉

+ +

+ $ apxs -i -A mod_foo.c +

+ +

apxs를 쉽게 사용하려고 다음과 같이 아파치 모듈 견본과 + Makefile을 만들 수 있다:

+ +

+ $ apxs -g -n foo
+ Creating [DIR] foo
+ Creating [FILE] foo/Makefile
+ Creating [FILE] foo/mod_foo.c
+ $ _ +

+ +

그런후 바로 견본 모듈을 공유객체로 컴파일하여 아파치 + 서버가 읽도록한다:

+ +

+ $ cd foo
+ $ make all reload
+ apxs -c mod_foo.c
+ gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
+ ld -Bshareable -o mod_foo.so mod_foo.o
+ apxs -i -a -n "foo" mod_foo.so
+ cp mod_foo.so /path/to/apache/modules/mod_foo.so
+ chmod 755 /path/to/apache/modules/mod_foo.so
+ [activating module `foo' in /path/to/apache/etc/httpd.conf]
+ apachectl restart
+ /path/to/apache/sbin/apachectl restart: httpd not running, trying to start
+ [Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
+ /path/to/apache/sbin/apachectl restart: httpd started
+ $ _ +

+ +

심지어 아파치 소스 밖에서 apxs를 사용하여 + PHP3와 같이 복잡한 모듈을 컴파일할 수 있다:

+ +

+ $ cd php3
+ $ ./configure --with-shared-apache=../apache-1.3
+ $ apxs -c -o libphp3.so mod_php3.c libmodphp3-so.a
+ gcc -fpic -DSHARED_MODULE -I/tmp/apache/include -c mod_php3.c
+ ld -Bshareable -o libphp3.so mod_php3.o libmodphp3-so.a
+ $ _ +

+ +

apxs는 자동으로 C 소스파일과 오브젝트파일을 + 구별한다. C 소스파일만 컴파일하고 나머지 오브젝트파일은 + 링크할때 사용한다.

+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/apxs.xml.ko b/docs/manual/programs/apxs.xml.ko index 85440ed7ee..367502b294 100644 --- a/docs/manual/programs/apxs.xml.ko +++ b/docs/manual/programs/apxs.xml.ko @@ -1,7 +1,7 @@ - + +configure - 소스 트리를 구성한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

configure - 소스 트리를 구성한다

+
+

가능한 언어:  en  | + ko 

+
+ +

configure 스크립트는 특정 플래폼에서 아파치 + 웹서버를 컴파일하고 설치하기위해 소스 트리를 구성한다. 여러 + 옵션을 사용하여 원하는 요구조건에 맞게 서버를 컴파일할 수 + 있다.

+ +

소스 배포본의 최상위 디렉토리에 있는 이 스크립트는 유닉스와 + 유닉스류 시스템에서만 사용한다. 다른 플래폼을 사용한다면 + 플래폼 문서를 참고하라.

+
+

참고

+
top
+
+

개요

+

configure 스크립트는 배포본의 최상위 + 디렉토리에서 실행해야 한다.

+ +

./configure [OPTION]... + [VAR=VALUE]...

+ +

환경변수를 (예를 들어, CC, CFLAGS, + ...) 지정하려면, VAR=VALUE와 + 같이 지시한다. 아래에서 유용한 환경변수들을 + 설명한다.

+
top
+
+

옵션

+ + +

구성 옵션

+ +

이 옵션들은 configure 자체 행동에 영향을 + 준다.

+ +
+
-C
+
--config-cache
+
--cache-file=config.cache와 같다.
+ +
--cache-file=FILE
+
검사 결과를 FILE 파일에 캐싱한다. + 기본값은 검사 결과를 기록하지 않는다.
+ +
-h
+
--help [short|recursive]
+
도움말을 출력하고 종료한다. short 아규먼트는 + 이 패키지 특유의 옵션만을 출력한다. recursive + 아규먼트는 포함된 모든 패키지에 대한 짧은 도움말을 + 보여준다.
+ +
-n
+
--no-create
+
configure 스크립트를 정상적으로 실행하지만, + 출력파일을 만들지 않는다. 이 옵션은 컴파일을 위한 makefile을 + 만들기 이전에 검사 결과를 확인해볼때 유용하다.
+ +
-q
+
--quiet
+
실행중에 checking ... 문구를 출력하지 + 않는다.
+ +
--srcdir=DIR
+
DIR 디렉토리를 소스파일 디렉토리로 지정한다. + 기본값은 configure가 있는 디렉토리 혹은 상위디렉토리 + ..이다.
+ +
--silent
+
--quiet와 같다.
+ +
-V
+
--version
+
저작권 정보를 출력하고 종료한다.
+
+ + +

설치 디렉토리

+ +

이 옵션들은 설치 디렉토리를 지정한다. 설치 위치는 + 선택한 구조(layout)에 따라 다르다.

+ +
+
--prefix=PREFIX
+
아키텍쳐에 독립적인 파일을 PREFIX에 설치한다. + 기본값은 /usr/local/apache2이다.
+ +
--exec-prefix=EPREFIX
+
아키텍쳐에 의존적인 파일을 EPREFIX에 설치한다. + 기본값은 PREFIX 디렉토리이다.
+
+ +

기본적으로 make install은 + /usr/local/apache2/bin, + /usr/local/apache2/lib와 같은 위치에 모든 + 파일을 설치한다. --prefix=$HOME과 같이 + --prefix 옵션을 사용하여 + /usr/local/apache2 이외의 설치 상위디렉토리를 + 지정할 수 있다.

+ +

디렉토리 구조 지정

+
+
--enable-layout=LAYOUT
+
설치 위치를 LAYOUT 구조에 따르도록 + 소스코드와 컴파일 스크립트를 구성한다. 구조를 사용하면 + 파일 종류에 따라 설치 위치를 따로 지정할 수 있다. + config.layout 파일에 여러 설정 예가 있고, + 이를 참고하여 직접 설정을 만들 수도 있다. 파일에서 + 각 구조는 <Layout + FOO>...</Layout>로 구분되며, 이 + 부분은 FOO라는 이름의 구조를 나타낸다. + 구조의 기본값은 Apache이다.
+
+ + +

설치 디렉토리의 + 자세한 조정

+ +

설치 디렉토리를 더 수정한다면 아래 옵션을 사용한다. + 각 디렉토리의 기본값은 autoconf가 지정하며, + 선택한 구조에 따라 다름을 주의하라.

+ +
+ +
--bindir=DIR
+
사용자 실행파일을 DIR에 설치한다. 사용자 + 실행파일에는 사이트 관리자에게 유용한 + htpasswd와 dbmmanage 같은 + 지원 프로그램도 포함된다. DIR의 기본값은 + EPREFIX/bin이다.
+ +
--datadir=DIR
+
아키텍쳐 독립적인 읽기전용 자료를 DIR에 + 설치한다. datadir의 기본값은 + PREFIX/share이다. + autoconf에 이 옵션이 있지만 현재 사용하지 + 않는다.
+ +
--includedir=DIR
+
C 헤더파일을 DIR에 설치한다. + includedir의 기본값은 + EPREFIX/include이다.
+ +
--infodir=DIR
+
info 문서를 DIR에 설치한다. + infodir의 기본값은 + PREFIX/info이다. 현재 이 옵션은 + 사용하지 않는다.
+ +
--libdir=DIR
+
오브젝트코드 라이브러리를 DIR에 설치한다. + libdir의 기본값은 + EPREFIX/lib이다.
+ +
--libexecdir=DIR
+
프로그램 실행파일을 (즉, 공유모듈) DIR에 + 설치한다. libexecdir의 기본값은 + EPREFIX/libexec이다.
+ +
--localstatedir=DIR
+
변경되는 머쉰별 정보를 DIR에 설치한다. + localstatedir의 기본값은 + PREFIX/var이다. + autoconf에 이 옵션이 있지만 현재 사용하지 + 않는다.
+ +
--mandir=DIR
+
man 문서를 DIR에 설치한다. + mandir의 기본값은 + EPREFIX/man이다.
+ +
--oldincludedir=DIR
+
gcc가 아닌 컴파일러를 위한 C 헤더파일을 DIR에 + 설치한다. oldincludedir의 기본값은 + /usr/include이다. autoconf에 + 이 옵션이 있지만 현재 사용하지 않는다.
+ +
--sbindir=DIR
+
시스템 관리자용 실행파일을 DIR에 설치한다. + 시스템 관리자용 실행파일이란 아파치 웹서버를 실행하는데 + 필요한 httpd, apachectl, + suexec 등 서버 프로그램을 말한다. + sbindir의 기본값은 + EPREFIX/sbin이다.
+ +
--sharedstatedir=DIR
+
변경되는 아키텍쳐 독립적인 자료를 DIR에 + 설치한다. sharedstatedir의 기본값은 + PREFIX/com이다. + autoconf에 이 옵션이 있지만 현재 사용하지 + 않는다.
+ +
--sysconfdir=DIR
+
서버 설정파일 httpd.conf, + mime.types와 같은 읽기전용 머쉰별 자료를 + DIR에 설치한다. sysconfdir의 + 기본값은 PREFIX/etc이다.
+
+ + + +

시스템 종류

+ +

다른 시스템에서 실행할 아파치 웹서버를 + 교차컴파일하기(cross-compile)하기 위한 옵션들이다. 서버를 + 컴파일한 시스템에서 서버를 실행하는 일반적인 경우, 이 + 옵션을 사용하지 않는다.

+ +
+
--build=BUILD
+
도구를 컴파일하는 시스템의 종류를 지정한다. 기본값은 + config.guess 스크립트의 결과이다.
+ +
--host=HOST
+
서버를 실행할 시스템의 종류를 지정한다. HOST의 + 기본값은 BUILD이다.
+ +
--target=TARGET
+
TARGET 시스템 종류를 위한 컴파일러를 만들때 + 사용한다. 기본값은 HOST이다. + autoconf에 이 옵션이 있지만 아파치 웹서버와는 + 관련이 없다.
+
+ + +

기능 선택

+ +

이 옵션은 웹서버의 세부 기능을 조절한다.

+ +

일반적인 문법

+

일반적으로 다음 문법을 사용하여 기능을 포함하고 뺀다:

+ +
+
--disable-FEATURE
+
FEATURE 기능을 뺀다. + --enable-FEATURE=no와 같다.
+ +
--enable-FEATURE[=ARG]
+
FEATURE 기능을 포함한다. ARG의 + 기본값은 yes이다.
+ +
--enable-MODULE=shared
+
해당 모듈을 DSO 모듈로 컴파일한다.
+ +
--enable-MODULE=static
+
포함하는 모듈은 기본적으로 정적으로 링크된다. 이 + 옵션은 명시적으로 정적 링크를 강제한다.
+
+ +

주의

+ configure는 foo가 없는 경우 + --enable-foo를 사용해도 이 사실을 + 알려주지 않으므로 주의해서 입력해야 한다. +
+ + + +

기본적으로 포함하는 모듈

+

어떤 모듈은 기본적으로 컴파일되기때문에 사용하지 않는다면 + 명시적으로 빼줘야 한다. 다음 옵션은 특정 모듈을 컴파일 + 과정에서 제외한다.

+ +
+
--disable-actions
+
mod_actions가 제공하는 요청에 대한 + 행동 기능을 사용하지 않는다.
+ +
--disable-alias
+
mod_alias가 제공하는 요청을 + 파일시스템의 다른 부분으로 대응하는 기능을 사용하지 + 않는다.
+ +
--disable-asis
+
mod_asis가 제공하는 as-is 파일형을 + 지원하지 않는다.
+ +
--disable-auth
+
mod_auth가 제공하는 사용자별 접근제어 + 기능을 사용하지 않는다. 이 모듈은 사용자명과 암호를 + 일반 문자파일에 저장하는 HTTP Basic Authentication에서 + 사용한다.
+ +
--disable-autoindex
+
mod_autoindex가 제공하는 디렉토리 + 목록 기능을 사용하지 않는다.
+ +
--disable-access
+
mod_access가 제공하는 호스트별 + 접근제어 기능을 사용하지 않는다.
+ +
--disable-cgi
+
비쓰레드 MPM을 사용하는 경우 CGI 스크립트를 지원하는 + mod_cgi를 기본적으로 포함한다. 이 + 옵션을 사용하면 CGI를 지원하지 않는다.
+ +
--disable-cgid
+
쓰레드 MPM인 worker나 + perchild를 사용하는 경우 기본적으로 + mod_cgid가 CGI 스크립트를 지원한다. + 이 옵션을 사용하면 CGI를 지원하지 않는다.
+ +
--disable-charset-lite
+
mod_charset_lite가 제공하는 문자집합 + 변환 기능을 사용하지 않는다. 이 모듈은 EBCDIC 시스템에서만 + 기본적으로 포함한다.
+ +
--disable-dir
+
mod_dir이 제공하는 디렉토리 요청 + 처리 기능을 사용하지 않는다.
+ +
--disable-env
+
mod_env가 제공하는 환경변수 설정/해제 + 기능을 사용하지 않는다.
+ + +
--disable-http
+
HTTP 프로토콜을 처리하지 않는다. http + 모듈은 서버가 웹서버로 동작하는데 기본적인 모듈이다. + 대신 다른 프로토콜 모듈을 사용할 경우에만 이 모듈이 + 유용하다. 자신이 무엇을 하는지 확실히 알지 + 못한다면 이 옵션을 빼지 마라 +
+ 주의: 이 모듈은 항상 정적으로 링크된다.
+ +
--disable-imap
+
mod_imap이 제공하는 서버기반 imagemap + 기능을 사용하지 않는다.
+ +
--disable-include
+
mod_include가 제공하는 Server Side + Includes 기능을 사용하지 않는다.
+ +
--disable-log-config
+
mod_log_config가 제공하는 로그 + 설정을 사용하지 않는다. 이 모듈이 없으면 서버의 요청을 + 로그에 기록할 수 없다.
+ +
--disable-mime
+
mod_mime은 요청한 파일명의 확장자에 + 따라 파일의 행동과 내용(mime-type, 언어, 문자집합, + 인코딩)을 결정한다. (이 모듈을 제거하여) 파일 확장자를 + MIME과 연관하지 않는 것을 일반적으로 추천하지 않는다.
+ +
--disable-negotiation
+
mod_negotiation이 제공하는 내용협상 + 기능을 사용하지 않는다.
+ +
--disable-setenvif
+
mod_setenvif가 제공하는 헤더에 + 따라 환경변수를 설정하는 기능을 사용하지 않는다.
+ +
--disable-status
+
mod_status가 제공하는 프로세스/쓰레드 + 감시 기능을 사용하지 않는다.
+ +
--disable-userdir
+
mod_userdir이 제공하는 요청을 사용자별 + 디렉토리에 대응하는 기능을 사용하지 않는다.
+
+ + +

기본적으로 포함하지 않는 모듈

+

기본적으로 컴파일되는 모듈도 있지만, 모듈을 사용하려면 + 직접 혹은 most나 all 키워드를 + 사용하여 명시적으로 포함해야 하는 모듈이 있다. 그래서 + 아래 옵션들을 사용한다.

+ +
+
--enable-auth-anon
+
mod_auth_anon이 제공하는 익명사용자 + 접근 기능을 사용한다.
+ +
--enable-auth-dbm
+
mod_auth_dbm은 사용자명과 암호를 + DBM형식의 데이터베이스 파일에 저장하는 HTTP Basic + Authentication에서 사용한다. 모듈을 사용하려면 이 + 옵션을 사용한다.
+ +
--enable-auth-digest
+
mod_auth_digest가 제공하는 RFC2617 + Digest authentication을 사용한다. 이 모듈은 정보를 + 일반 문자파일에 저장한다.
+ +
--enable-auth-ldap
+
mod_auth_ldap이 제공하는 LDAP기반 + 인증 기능을 사용한다.
+ +
--enable-cache
+
mod_cache가 제공하는 동적으로 생성하는 + 파일의 캐싱 기능을 사용한다. 매우 부하가 많거나 프록시 + 서버를 캐싱하는 서버에게 이 실험적인 모듈이 유용할 + 수 있다. 최소한 한가지 저장관리모듈(storage management + module)을 (예를 들어, mod_disk_cache나 + mod_mem_cache) 같이 사용해야 한다.
+ +
--enable-cern-meta
+
mod_cern_meta가 제공하는 CERN 메타파일 + 지원 기능을 사용한다.
+ +
--enable-charset-lite
+
mod_charset_lite가 제공하는 문자집합 + 변환 기능을 사용한다. 이 모듈은 EBCDIC 시스템에서만 + 기본적으로 포함된다. 다른 시스템에서는 직접 포함시켜줘야 + 한다.
+ +
--enable-dav
+
mod_dav가 제공하는 WebDAV 프로토콜 + 처리 기능을 사용한다. 독립된 mod_dav_fs + 모듈이 파일시스템 자원을 지원한다. 이 모듈은 + --enable-dav를 사용하면 자동으로 포함한다.
+ 주의: mod_dav는 http + 프로토콜 모듈과 같이 사용해야 한다.
+ +
--enable-dav-fs
+
mod_dav_fs가 제공하는 DAV의 파일시스템 + 자원 지원 기능을 사용한다. 이 모듈은 + mod_dav 모듈을 위한 제공자이기 때문에 + --enable-dav도 사용해야 한다.
+ +
--enable-deflate
+
mod_deflate가 제공하는 압축전송 + 인코딩 기능을 사용한다.
+ +
--enable-disk-cache
+
mod_disk_cache가 제공하는 디스크 + 캐싱 기능을 사용한다.
+ +
--enable-expires
+
mod_expires가 제공하는 Expires + 헤더 조절 기능을 사용한다.
+ +
--enable-ext-filter
+
mod_ext_filter가 제공하는 외부 + 필터 지원 기능을 사용한다.
+ +
--enable-file-cache
+
mod_file_cache가 제공하는 파일 + 캐싱 기능을 사용한다.
+ +
--enable-headers
+
mod_headers가 제공하는 HTTP 헤더 + 조절 기능을 사용한다.
+ +
--enable-info
+
mod_info가 제공하는 서버정보 기능을 + 사용한다.
+ +
--enable-ldap
+
mod_ldap이 제공하는 LDAP 캐싱과 + 연결풀 기능을 사용한다.
+ +
--enable-logio
+
mod_logio가 제공하는 로그에 헤더와 + 입출력 바이트수를 기록하는 기능을 사용한다.
+ +
--enable-mem-cache
+
mod_mem_cache가 제공하는 메모리 + 캐싱 기능을 사용한다.
+ +
--enable-mime-magic
+
mod_mime_magic이 제공하는 MIME + type 자동 인식 기능을 사용한다.
+ +
--enable-isapi
+
mod_isapi가 제공하는 isapi 확장을 + 지원한다.
+ +
--enable-proxy
+
mod_proxy가 제공하는 프록시/게이트웨이 + 기능을 사용한다. CONNECT, FTP, + HTTP에 대한 프록시 기능을 각각 + mod_proxy_connect, + mod_proxy_ftp, + mod_proxy_http + 모듈이 제공한다. --enable-proxy를 사용하면 + 이 세 모듈을 자동으로 포함한다.
+ +
--enable-proxy-connect
+
mod_proxy_connect가 제공하는 + CONNECT 요청에 대한 프록시 지원 기능을 + 사용한다. 이 모듈은 mod_proxy 모듈의 + 확장이므로, --enable-proxy도 같이 사용해야 + 한다.
+ +
--enable-proxy-ftp
+
mod_proxy_ftp가 제공하는 + FTP 요청에 대한 프록시 지원 기능을 사용한다. + 이 모듈은 mod_proxy 모듈의 확장이므로, + --enable-proxy도 같이 사용해야 한다.
+ +
--enable-proxy-http
+
mod_proxy_http가 제공하는 + HTTP 요청에 대한 프록시 지원 기능을 사용한다. + 이 모듈은 mod_proxy 모듈의 확장이므로, + --enable-proxy도 같이 사용해야 한다.
+ +
--enable-rewrite
+
mod_rewrite가 제공하는 규칙기반 + URL 조작 기능을 사용한다.
+ +
--enable-so
+
mod_so가 제공하는 DSO 기능을 사용한다. + --enable-mods-shared 옵션을 사용하면 + 자동으로 이 모듈을 포함한다.
+ +
--enable-speling
+
mod_spelling이 제공하는 URL에서 + 일반적인 맞춤법 실수를 고치는 기능을 사용한다.
+ +
--enable-ssl
+
mod_ssl이 제공하는 SSL/TLS 기능을 + 사용한다.
+ +
--enable-unique-id
+
mod_unique_id가 제공하는 요청마다 + 유일한 식별자를 만드는 기능을 사용한다.
+ +
--enable-usertrack
+
mod_usertrack이 제공하는 사용자세션 + 추적 기능을 사용한다.
+ +
--enable-vhost-alias
+
mod_vhost_alias가 제공하는 대량 + 가상호스트 기능을 사용한다.
+
+ + +

개발자를 위한 모듈

+

다음 모듈은 테스트용으로 개발자에게만 유용하며, 기본적으로 + 포함하지 않는다. 이 모듈을 사용하려면 다음 옵션을 사용한다. + 이 모듈이 필요한지 확실치않다면 사용하지 마라.

+ +
+ +
--enable-bucketeer
+
mod_bucketeer가 제공하는 버킷(bucket) + 조작 필터를 사용한다.
+ + +
--enable-case-filter
+
mod_case_filter의 대문자변환 출력필터 + 견본을 사용한다.
+ + +
--enable-case-filter-in
+
mod_case_filter_in의 대문자변환 입력필터 + 견본을 사용한다.
+ +
--enable-echo
+
mod_echo가 제공하는 ECHO 서버를 + 사용한다.
+ +
--enable-example
+
견본 예제모듈인 mod_example을 + 사용한다.
+ + +
--enable-optional-fn-export
+
mod_optional_fn_export가 제공하는 선택적인 + 함수 엑스포트(exporter)의 예를 사용한다.
+ + +
--enable-optional-fn-import
+
mod_optional_fn_import가 제공하는 선택적인 + 함수 임포트(importer)의 예를 사용한다.
+ + +
--enable-optional-hook-export
+
mod_optional_hook_export가 제공하는 + 선택적인 훅(hook) 엑스포트의 예를 사용한다.
+ + +
--enable-optional-hook-import
+
mod_optional_hook_import가 제공하는 + 선택적인 훅 임포트의 예를 사용한다.
+
+ + +

MPM과 제삼자가 만든 모듈

+

다음 옵션을 사용하여 필요한 다중처리모듈과 제삼자가 + 만든 모듈을 추가한다:

+ +
+
--with-module=module-type:module-file +
+

제삼자가 만든 모듈을 정적으로 링크할 모듈 목록에 + 추가한다. 아파치 웹서버 소스 트리의 + modules/module-type에서 모듈의 + 소스파일 module-file을 찾기때문에 + 그곳에 소스파일이 있어야 한다. 그곳에 파일이 없다면 + configure는 module-file이 + 절대파일경로라고 가정하고 소스파일을 + module-type 하위디렉토리에 복사하려고 + 시도한다.

+

이 옵션은 소스파일이 한개인 작은 외부 모듈을 추가하는데 + 유용하다. 더 복잡한 모듈은 개발사가 제공한 문서를 + 참고해야 한다.

+

주의

+ 정적으로 링크된 모듈이 아닌 DSO 모듈을 원한다면 + apxs를 사용하라.
+
+ +
--with-mpm=MPM
+
서버의 동작방식을 선택한다. 정확히 한가지 다중처리모듈만을 선택해야 한다. + 선택하지 않으면 사용하는 운영체제의 기본 MPM을 사용한다. + 사용할 수 있는 MPM에는 beos, + leader, mpmt_os2, + perchild, prefork, + threadpool, worker가 + 있다.
+
+ + +

기타 옵션

+
+
--enable-maintainer-mode
+
디버깅 모드와 컴파일시 경고를 작동한다.
+ +
--enable-mods-shared=MODULE-LIST
+
+

동적공유모듈로 컴파일할 모듈 목록을 지정한다. 즉, + 이 모듈들은 LoadModule 지시어를 + 사용하여 동적으로 읽어들여야 한다.

+

MODULE-LIST는 공백으로 구분한 모듈명들을 + 따옴표로 묶은 목록이다. 모듈명에서 앞에 + mod_는 뺀다. 예를 들어:

+

+ --enable-mods-shared='headers rewrite dav' +

+

또, 특별한 키워드 all과 most를 + 사용할 수 있다. 예를 들어,

+

+ --enable-mods-shared=most +

+

는 대부분의 모듈을 DSO 모듈로 컴파일한다. +

+
+ +
--enable-modules=MODULE-LIST
+
--enable-mods-shared와 비슷하지만, + 이 옵션은 열거한 모듈들을 정적으로 링크한다. 즉, 이 + 모듈들은 httpd 실행하면 언제나 사용할 + 수 있다. LoadModule로 읽어들일 + 필요가 없다.
+ +
--enable-v4-mapped
+
IPv6 소켓이 IPv4 연결을 처리할 수 있도록 한다.
+ +
--with-port=PORT
+
httpd가 기다릴 포트를 지정한다. 이 + 포트번호는 설정파일 httpd.conf를 만들때 + 쓰인다. 기본값은 80이다.
+ +
--with-program-name
+
다른 실행파일명을 지정한다. 기본값은 + httpd이다.
+
+ + + +

추가 패키지 선택

+

다음 옵션은 추가 패키지를 선택한다.

+ +

일반적인 문법

+

일반적으로 다음과 같은 문법을 사용하여 추가 패키지를 + 다룬다:

+ +
+
--with-PACKAGE[=ARG]
+
패키지 PACKAGE를 사용한다. + ARG의 기본값은 yes이다.
+ +
--without-PACKAGE
+
패키지 PACKAGE를 사용하지 않는다. + --with-PACKAGE=no와 같다. + autoconf에 이 옵션이 있지만 아파치 웹서버와는 + 관계가 없다.
+
+ + + + +

특정 패키지

+
+
--with-apr=DIR|FILE
+
httpd 소스 배포본에 포함된 Apache Portable + Runtime (APR)은 자동으로 웹서버와 같이 컴파일된다. + 만약 이미 설치된 APR을 대신 사용하고 싶다면 + configure에게 apr-config + 스크립트의 경로를 알려주어야 한다. APR가 설치된 절대경로, + 파일명, 디렉토리명을 사용할 수 있다. 지정한 디렉토리나 + 그 디렉토리의 하위디렉토리 bin에 + apr-config가 있어야 한다.
+ +
--with-apr-util=DIR|FILE
+
httpd 소스 배포본에 포함된 Apache Portable + Runtime Utilities (APU)는 자동으로 웹서버와 같이 + 컴파일된다. 만약 이미 설치된 APU을 대신 사용하고 싶다면 + configure에게 apu-config + 스크립트의 경로를 알려주어야 한다. APU가 설치된 절대경로, + 파일명, 디렉토리명을 사용할 수 있다. 지정한 디렉토리나 + 그 디렉토리의 하위디렉토리 bin에 + apu-config가 있어야 한다.
+ +
--with-ssl=DIR
+
mod_ssl을 사용하는 경우 + configure는 설치된 OpenSSL을 찾는다. + 대신 이 옵션을 사용하여 SSL/TLS 도구의 디렉토리경로를 + 알려줄 수 있다.
+ +
--with-z=DIR
+
(mod_deflate를 사용하는 경우와 + 같이) 구성에 필요하다면 자동으로 configure는 + 설치된 zlib 라이브러리를 찾는다. 대신 + 이 옵션을 사용하여 압축 라이브러리의 디렉토리경로를 + 알려줄 수 있다.
+
+ +

mod_authn_dbm과 + mod_rewrite의 DBM RewriteMap 같은 아파치 + 웹서버의 일부 기능은 정보를 빨리 찾기위해 간단한 키/값 + 데이터베이스를 사용한다. APU에 SDBM이 들어있어서 언제나 + 최소한 이 데이터베이스는 사용할 수 있다. 다른 종류의 + 데이터베이스를 사용하고 싶다면 아래 옵션을 사용한다:

+ +
+
--with-gdbm[=path]
+
path를 지정하지 않으면, + configure는 일반적인 검색경로에서 설치된 + GNU DBM 헤더파일과 라이브러리를 찾는다. 직접 + path를 지정하면 configure는 + path/lib과 + path/include에서 필요한 파일을 + 찾는다. 마지막으로 path에 헤더파일 경로와 + 라이브러리 경로를 콜론을 사이에 두고 같이 적을 수 + 있다.
+ +
--with-ndbm[=path]
+
--with-gdbm과 같지만 설치된 New DBM을 + 찾는다.
+ +
--with-berkeley-db[=path]
+
--with-gdbm과 같지만 설치된 Berkeley + DB를 찾는다.
+
+ +

주의

+

DBM 옵션은 APU가 제공하며 APU 구성스크립트로 직접 + 전달된다. 그래서 --with-apr-util을 사용하여 + 이미 설치된 APU를 사용한다면 DBM 옵션은 소용이 없다.

+

웹서버는 여러 DBM 구현을 같이 사용할 수 있다. 실행시 + 적절한 DBM 종류를 설정할 수 있다.

+
+ + + +

지원 프로그램을 위한 옵션

+
+
--enable-static-support
+
지원 프로그램을 정적으로 링크된 실행파일로 만든다. + 즉, 필요한 라이브러리를 모두 포함하도록 실행파일을 + 컴파일한다. 이 옵션을 사용하지 않으면 기본값으로 지원 + 프로그램을 동적으로 링크한다.
+ +
--enable-suexec
+
웹서버가 실행하는 프로세스의 uid와 gid를 설정하는 + suexec를 사용하려면 + 이 옵션을 사용한다. suid 실행파일의 보안상 위험을 + 모두 알지 못한다면 이 옵션을 사용하지 마라. + suexec를 구성하는 옵션은 + 아래에서 설명한다.
+
+ +

다음 옵션을 사용하여 지원 프로그램별로 정적으로 링크된 + 실행파일을 만들 수 있다:

+ +
+
--enable-static-ab
+
ab를 정적으로 링크된 + 실행파일로 컴파일한다.
+ + +
--enable-static-checkgid
+
checkgid를 정적으로 링크된 실행파일로 + 컴파일한다.
+ + +
--enable-static-htdbm
+
htdbm을 정적으로 링크된 실행파일로 + 컴파일한다.
+ +
--enable-static-htdigest
+
htdigest를 + 정적으로 링크된 실행파일로 컴파일한다.
+ +
--enable-static-htpasswd
+
htpasswd를 + 정적으로 링크된 실행파일로 컴파일한다.
+ +
--enable-static-logresolve
+
logresolve를 + 정적으로 링크된 실행파일로 컴파일한다.
+ +
--enable-static-rotatelogs
+
rotatelogs를 + 정적으로 링크된 실행파일로 컴파일한다.
+
+ +

suexec 설정 옵션

+

아래 옵션은 suexec를 자세히 설정한다. + 더 자세한 정보는 suEXEC + 구성과 설치를 참고하라.

+ +
+
--with-suexec-bin
+
suexec 실행파일의 경로를 지정한다. 기본값은 + --sbindir이다 (설치 디렉토리의 자세한 + 조정 참고).
+ +
--with-suexec-caller
+
suexec를 실행할 사용자를 지정한다. + 이 사용자는 보통 httpd를 실행하는 사용자와 + 같아야 한다.
+ +
--with-suexec-docroot
+
suexec는 이 옵션으로 지정한 디렉토리 + 아래에 있는 실행파일만을 실행할 수 있다. 기본값은 + --datadir/htdocs다.
+ +
--with-suexec-gidmin
+
suexec에서 지정가능한 최소 GID를 설정한다. + 기본값은 100이다.
+ +
--with-suexec-logfile
+
suexec 로그파일명을 지정한다. 로그파일명의 + 기본값은 suexec_log이고, + --logfiledir에 위치한다.
+ +
--with-suexec-safepath
+
suexec가 시작하는 프로세스의 + PATH 환경변수값을 지정한다. 기본값은 + /usr/local/bin:/usr/bin:/bin이다.
+ +
--with-suexec-userdir
+
사용자 디렉토리에서 suexec가 접근할 + 수 있는 (실행파일이 있는) 하위디렉토리를 지정한다. + 이 설정은 suexec와 + (mod_userdir이 제공하는) 사용자별 + 디렉토리를 같이 사용할때 필요하다. 기본값은 + public_html이다.
+ +
--with-suexec-uidmin
+
suexec에서 지정가능한 최소 UID를 설정한다. + 기본값은 100이다.
+ +
--with-suexec-umask
+
suexec가 실행하는 프로세스의 + umask를 지정한다. 기본값은 사용하는 시스템의 + 기본 설정과 같다.
+
+ + +
top
+
+

환경변수

+

configure의 선택을 무시하거나 관례와 다른 + 이름이나 위치에 있는 라이브러리와 프로그램을 찾도록 도와주는 + 유용한 환경변수들이 있다.

+ + +
+
CC
+
컴파일에 사용할 C 컴파일러 명령어를 지정한다.
+ +
CFLAGS
+
컴파일때 사용하길 바라는 C 컴파일러 옵션을 지정한다.
+ +
CPP
+
사용할 C 선처리기 명령어를 지정한다.
+ +
CPPFLAGS
+
C/C++ 선처리기 옵션. 예를 들어, 헤더파일이 관례와 달리 + includedir 디렉토리에 있다면 + -Iincludedir을 사용한다.
+ +
LDFLAGS
+
링커 옵션. 예를 들어, 라이브러리가 관례와 달리 + libdir 디렉토리에 있다면 + -Llibdir을 사용한다.
+
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/configure.xml.ko b/docs/manual/programs/configure.xml.ko index d50902274d..b66796571a 100644 --- a/docs/manual/programs/configure.xml.ko +++ b/docs/manual/programs/configure.xml.ko @@ -1,7 +1,7 @@ - + +dbmmanage - DBM 형식의 사용자인증 파일을 관리한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

dbmmanage - DBM 형식의 사용자인증 파일을 관리한다

+
+

가능한 언어:  en  | + ko 

+
+ +

dbmmanage는 HTTP basic authentication에 + 사용할 사용자명과 암호를 저장하는 DBM형식의 파일을 만들고 + 수정한다. 아파치 웹서버는 자원을 dbmmanage로 + 만든 파일에 기록한 사용자에게만 보여줄 수 있다. 사용자명이 + DBM 파일에 기록되있을때만 이 프로그램을 사용할 수 있다. + 일반파일을 데이터베이스로 사용하려면 htpasswd를 참고하라.

+ +

이 manpage는 명령행 옵션만을 설명한다. httpd에서 사용자인증을 설정하는 지시어에 + 대한 설명은 아파치 배포본에 포함되있고 http://httpd.apache.org/에서도 + 볼 수 있는 아파치 설명서를 참고하라.

+
+

참고

+
top
+
+

개요

+

dbmmanage [ encoding ] + filename add|adduser|check|delete|update + username + [ encpasswd + [ group[,group...] + [ comment ] ] ]

+ +

dbmmanage filename + view [ username ]

+ +

dbmmanage filename import

+
top
+
+

옵션

+
+
filename
+
DBM형식 파일의 파일명. 보통 .db, + .pag, .dir 확장자를 뺀다.
+ +
username
+
작업할 사용자명. username에 콜론(:)을 + 사용할 수 없다.
+ +
encpasswd
+
update나 add 명령에 사용할 + 이미 암호화된 암호이다. 암호를 나중에 지정하고 싶은 경우 + 빼기기호(-)를 사용한다. 또, update + 명령을 사용할때 마침표(.)를 사용하면 원래 + 암호를 그대로 둔다.
+ +
group
+
사용자가 속한 그룹. 그룹명에 콜론(:)을 + 사용할 수 없다. 사용자를 그룹에 추가하지는 않지만 설명란을 + 채우고 싶다면 빼기기호(-)를 사용한다. 또, + update 명령을 사용할때 마침표(.)를 + 사용한다면 원래 그룹을 그대로 둔다.
+ +
comment
+
실제 이름, 메일 주소 등 사용자에 대한 설명을 적는 란이다. + 서버는 이 항목을 무시한다.
+
+ +

인코딩

+
+
-d
+
crypt 암호화 (Win32나 Netware가 아니라면 기본값)
+ +
-m
+
MD5 암호화 (Win32과 Netware에서 기본값)
+ +
-s
+
SHA1 암호화
+ +
-p
+
암호를 그대로 기록 (추천하지 않음)
+
+ + +

명령

+
+
add
+
암호화된 암호 encpasswd를 사용하여 + filename에 username 항목을 추가한다.
+ +
adduser
+
암호를 물어보고 filename에 + username 항목을 추가한다.
+ +
check
+
암호를 물어본후 filename에 + username이 있고 암호가 일치하는지 검사한다.
+ +
delete
+
filename에서 username 항목을 + 삭제한다.
+ +
import
+
STDIN에서 + username:password 항목을 + (한줄에 하나씩) 읽어서 filename에 추가한다. + 암호는 이미 암호화되있어야 한다.
+ +
update
+
adduser 명령과 비슷하지만, + filename에 이미 username이 있는지 + 확인한다.
+ +
view
+
DBM 파일 내용을 출력한다. username을 + 지정하면 특정 항목만을 출력한다.
+
+ +
top
+
+

버그

+

여러 다른 DBM 파일형식들이 있고 당신의 시스템에 여러 + 형식에 대한 비슷한 라이브러리들이 있음을 주의해야 한다. + 가장 대표적인 네가지가 SDBM, NDBM, GNU 프로젝트의 GDBM, + Berkeley DB 2이다. 불행히도 이 라이브러리들은 모두 다른 + 파일형식을 사용한다. 그래서 filename이 사용하는 + 파일형식이 dbmmanage가 원하는 형식과 같은지 + 확인해야 한다. dbmmanage는 DBM 파일의 형식을 + 알아내지 못한다. 다른 형식을 사용하면 아무일도 하지 않거나, + 다름 이름의 DBM 파일을 만들거나, 최악의 경우 파일을 기록하여 + DBM 파일을 망칠 수 있다.

+ +

dbmmanage 프로그램 앞부분에 있는 + @AnyDBM::ISA 배열이 DBM형식 선호순서이다. + 우리는 Berkeley DB 2 파일형식을 선호하므로 + dbmmanage가 시스템 라이브러리를 찾는 순서는 + Berkeley DB 2, NDBM, GDBM, SDBM 순이다. dbmmanage는 + 제일 먼저 찾은 라이브러리를 사용하여 모든 DBM 파일 작업을 + 한다. 이 순서는 Perl의 간단한 dbmopen() 호출이 + 사용하는 순서나 Perl의 표준 @AnyDBM::ISA 순서와 + 조금 다르다. 그래서 다른 도구를 사용하여 DBM 파일을 관리한다면 + 이 순서를 따라야 한다. C와 같이 다른 언어로 작성한 프로그램을 + 사용하여 파일을 다루는 경우에도 마찬가지다.

+ +

대부분의 유닉스 시스템에서 file 프로그램으로 + DBM 파일형식을 확인할 수 있다.

+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/dbmmanage.xml.ko b/docs/manual/programs/dbmmanage.xml.ko index f8256b0e04..8094b458ca 100644 --- a/docs/manual/programs/dbmmanage.xml.ko +++ b/docs/manual/programs/dbmmanage.xml.ko @@ -1,7 +1,7 @@ - + +htdigest - digest authentication에 사용할 사용자파일을 +관리한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

htdigest - digest authentication에 사용할 사용자파일을 +관리한다

+
+

가능한 언어:  en  | + ko 

+
+ +

htdigest는 HTTP 사용자의 digest authentication에 + 사용할 사용자명, 영역, 암호를 저장하는 일반파일을 만들고 + 수정한다. 아파치 웹서버는 자원을 htdigest로 + 만든 파일에 기록한 사용자에게만 보여줄 수 있다.

+ +

이 manpage는 명령행 옵션만을 설명한다. httpd에서 digest authentication을 + 설정하는 지시어에 대한 설명은 아파치 배포본에 포함되있고 + http://httpd.apache.org/에서도 + 볼 수 있는 아파치 설명서를 참고하라.

+
+

참고

+
top
+
+

개요

+

htdigest [ -c ] + passwdfile realm username

+
top
+
+

옵션

+
+
-c
+
passwdfile을 만든다. passwdfile이 + 이미 있다면 먼저 지우고 만든다.
+ +
passwdfile
+
사용자명, 영역, 암호를 저장할 파일명. -c를 + 같이 사용한 경우 파일이 없다면 만들고, 있다면 파일을 지우고 + 다시 만든다.
+ +
realm
+
사용자명이 속한 영역이름.
+ +
username
+
passwdfile에 만들거나 수정할 사용자명. 파일에 + username이 없다면 항목을 추가한다. 있다면 암호를 + 수정한다.
+
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/htdigest.xml.ko b/docs/manual/programs/htdigest.xml.ko index 0b1b8bceaa..df0b4186ec 100644 --- a/docs/manual/programs/htdigest.xml.ko +++ b/docs/manual/programs/htdigest.xml.ko @@ -1,7 +1,7 @@ - + +htpasswd - basic authentication에 사용할 사용자파일을 + 관리한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

htpasswd - basic authentication에 사용할 사용자파일을 + 관리한다

+
+

가능한 언어:  en  | + ko 

+
+ +

htpasswd는 HTTP basic authentication에 사용할 + 사용자명과 암호를 저장하는 일반파일을 생성하고 수정한다. + htpasswd가 파일을 쓰거나 읽을 수 없다면, + 오류상태를 반환하고 아무것도 수정하지 않는다.

+ +

아파치 웹서버는 자원을 htpasswd로 만든 파일에 + 기록한 사용자에게만 보여줄 수 있다. 이 프로그램은 사용자명과 + 암호를 저장하는 일반 파일을 관리한다. 그러나 다른 자료저장 + 방식을 위해 암호 정보를 암호화하여 저장할 수 있다. DBM + 데이터베이스를 사용하려면 dbmmanage를 참고하라.

+ +

htpasswd는 아파치 특유의 MD5 혹은 시스템의 + crypt()를 사용하여 암호를 암호화한다. + htpasswd가 관리하는 파일은 두 종류의 암호를 + 모두 저장할 수 있다. 즉, 같은 파일에 MD5로 암호화한 암호를 + 사용하는 사용자와 crypt()로 암호화한 암호를 + 사용하는 사용자 정보 모두 나올 수 있다.

+ +

이 manpage는 명령행 옵션만을 설명한다. httpd에서 사용자인증을 설정하는 지시어에 + 대한 설명은 아파치 배포본에 포함되있고 http://httpd.apache.org/에서도 + 볼 수 있는 아파치 설명서를 참고하라.

+
+

참고

+
top
+
+

개요

+

htpasswd + [ -c ] + [ -m ] + [ -D ] passwdfile username

+ +

htpasswd -b + [ -c ] + [ -m | + -d | + -p | + -s ] + [ -D ] passwdfile username + password

+ +

htpasswd -n + [ -m | + -d | + -s | + -p ] username

+ +

htpasswd -nb + [ -m | + -d | + -s | + -p ] username password

+
top
+
+

옵션

+
+
-b
+
배치(batch) 모드를 사용한다. 예를 들어, 암호를 + 물어보지않고 명령행에서 받는다. 명령행에 암호가 + 직접 드러나므로, 이 옵션은 매우 조심해서 사용해야 + 한다.
+ +
-c
+
passwdfile을 만든다. passwdfile이 + 이미 존재한다면, 덮어쓴다. 이 옵션을 -n 옵션과 + 같이 사용할 수 없다.
+ +
-n
+
파일을 수정하지않고 결과를 표준출력으로 출력한다. + 아파치가 문서이외의 곳에 생성한 암호를 저장할때 유용하다. + (항상 첫번째 아규먼트인) passwdfile 아규먼트가 + 없기때문에 명령행 문법이 다르다. -c 옵션과 + 같이 사용할 수 없다.
+ +
-m
+
MD5를 사용하여 암호를 암호화한다. Windows, Netware, + TPF에서 기본값이다.
+ +
-d
+
crypt()를 사용하여 암호를 암호화한다. + Windows, Netware, TPF를 제외한 모든 플래폼에서 기본값이다. + 모든 플래폼의 htpasswd가 이 형식을 지원할 수는 + 있지만, Windows, Netware, TPF의 httpd + 서버는 이 형식을 지원하지 않는다.
+ +
-s
+
암호를 SHA 암호화한다. LDAP 디렉토리교환형식(ldif)을 + 사용하여 Netscape 서버로 정보를 보내거나 거져올때 유용하다.
+ +
-p
+
암호를 그대로 사용한다. 모든 플래폼의 htpasswd가 + 지원하지만, Windows, Netware, TPF의 httpd + 데몬만이 일반 암호를 받는다.
+ +
-D
+
사용자를 삭제한다. htpasswd 파일에 사용자명이 있다면 + 삭제한다.
+ +
passwdfile
+
사용자명과 암호를 저장하는 파일명. -c를 + 사용한 경우 파일이 없다면 새로 만들고, 있다면 덮어쓴다.
+ +
username
+
passwdfile에 만들거나 수정할 사용자명. + username이 이 파일에 없다면 항목을 추가한다. + 있다면 암호를 수정한다.
+ +
password
+
암호화하여 파일에 저장할 암호. 오직 -b + 옵션과 같이 사용할 수 있다.
+
+
top
+
+

종료코드

+

htpasswd는 passwdfile에 사용자명과 + 암호를 성공적으로 추가하거나 수정한 경우 ("참") 종료코드 + 0을 반환한다. htpasswd는 파일에 접근할때 문제가 + 발생한 경우 1을, 명령행 형식이 잘못된 경우 + 2를, 입력한 암호와 확인차 다시 입력한 값이 + 일치하지 않은 경우 3을, 명령이 중단된 경우 + 4를, (사용자명, 파일명, 암호, 최종 계산결과) + 값이 너무 긴 경우 5를, 사용자명에 허용하지않는 + 문자가 포함된 경우 제한 절 참고) + 6를, 파일이 올바른 암호파일이 아닌 경우 + 7을 반환한다.

+
top
+
+

예제

+

+ htpasswd /usr/local/etc/apache/.htpasswd-users jsmith +

+ +

사용자 jsmith의 암호를 추가하거나 수정한다. + 사용자에게 암호를 물어본다. Windows 시스템에서 실행하면 + 암호를 아파치 특유의 MD5 알고리즘을 사용하여 암호화하고, + 아니면 시스템의 crypt() 함수를 사용한다. 파일이 + 없다면 htpasswd는 아무 일도 하지않고 오류를 + 낸다.

+ +

+ htpasswd -c /home/doe/public_html/.htpasswd jane +

+ +

새로 파일을 만들고 그 파일에 사용자 jane을 + 추가한다. 사용자에게 암호를 물어본다. 파일이 있지만 읽거나 + 쓸 수 없다면, htpasswd는 파일을 수정하지않고 + 문구를 출력한후 오류상태를 반환한다.

+ +

+ htpasswd -mb /usr/web/.htpasswd-all jones Pwd4Steve +

+ +

명령행의 암호(Pwd4Steve)를 MD5 알고리즘으로 + 암호화하여 지정한 파일에 저장한다.

+
top
+
+

보안상 고려할 점

+

htpasswd 등이 관리하는 웹 암호파일이 웹서버의 + URI 공간에 있으면 안된다. 즉, 브라우저가 이 파일을 + 볼 수 없어야 한다.

+ +

명령행에 암호화하지않은 암호를 사용하기때문에 -b + 옵션을 추천하지 않는다.

+
top
+
+

제한

+

Windows와 MPE 플래폼은 htpasswd가 암호화하는 + 암호의 길이를 255 문자로 제한한다. 더 긴 암호는 + 255자에서 짤린다.

+ +

htpasswd가 사용하는 MD5 알고리즘은 아파치 + 소프트웨어 특유의 것이다. 이를 사용하여 암호화한 암호를 + 다른 웹서버에서 사용할 수 없다.

+ +

사용자명은 255 바이트로 제한되고 : + 문자를 포함할 수 없다.

+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/htpasswd.xml.ko b/docs/manual/programs/htpasswd.xml.ko index 1a984e7184..f2f55bb174 100644 --- a/docs/manual/programs/htpasswd.xml.ko +++ b/docs/manual/programs/htpasswd.xml.ko @@ -1,7 +1,7 @@ - + +httpd - 아파치 하이퍼텍스트 전송 프로토콜 서버 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

httpd - 아파치 하이퍼텍스트 전송 프로토콜 서버

+
+

가능한 언어:  en  | + ko 

+
+ +

httpd는 아파치 하이퍼텍스트 전송 프로토콜 + (HTTP) 서버 프로그램이다. 자체(standalone) 데몬 프로세스로 + 실행하도록 설계되었다. 원한다면 요청을 처리하기위해 자식 + 프로세스와 쓰레드들을 만든다.

+ +

일반적으로 httpd를 직접 실행하기보다는 + 유닉스기반 시스템에서는 apachectl을 통해, 2000, XP에서는 + 서비스로, Windows + 9x와 ME에서는 콜솔 프로그램으로 실행해야 한다.

+
+

참고

+
top
+
+

개요

+

httpd [ -d + serverroot ] [ -f config ] + [ -C directive ] [ -c + directive ] [ -D parameter ] + [ -e level ] [ -E + file ] [ -k start|restart|graceful|stop ] + [ -R directory ] [ -h ] + [ -l ] [ -L ] [ -S ] + [ -t ] [ -v ] [ -V ] + [ -X ]

+ +

Windows 시스템에서는 + 다음 아규먼트를 추가로 사용할 수 있다:

+ +

httpd [ -k + install|config|uninstall ] [ -n name ] + [ -w ]

+
top
+
+

옵션

+ +
+
-d serverroot
+ +
ServerRoot 지시어의 +기본값을 serverroot로 설정한다. 설정파일에서 ServerRoot +지시어를 사용하여 이 값을 수정할 수 있다. 기본값은 +/usr/local/apache2이다.
+ +
-f config
+ +
시작할때 config 파일에 있는 지시어를 사용한다. +config가 /로 시작하지 않으면 ServerRoot에 상대경로이다. 기본값은 +conf/httpd.conf이다.
+ +
-k start|restart|graceful|stop
+ +
httpd를 시작, 재시작, 중단한다. 더 자세한 정보는 +아파치 중단하기를 참고하라.
+ +
-C directive
+ +
설정파일을 읽기전에 directive 지시어를 처리한다.
+ +
-c directive
+ +
설정파일을 읽기전에 directive 지시어를 처리한다.
+ + +
-D parameter
+ +
서버 시작 혹은 재시작시 선택적으로 명령어를 처리하기위해 +설정파일의 <IfDefine> +섹션에 사용할 parameter를 설정한다.
+ +
-e level
+ +
서버가 시작하는동안 LogLevel을 +level로 설정한다. 이는 시작중 문제를 찾기위해 잠시 +더 자세한 오류문을 얻을때 유용하다.
+ +
-E file
+ +
서버가 시작하는동안 file로 오류문을 보낸다.
+ +
-R directory
+ +
서버를 SHARED_CORE 규칙을 사용하여 컴파일한 +경우 공유오브젝트파일 directory를 지정한다.
+ +
-h
+ +
사용할 수 있는 명령행 옵션들의 짧은 요약을 출력한다.
+ +
-l
+ +
서버에 같이 컴파일한 모듈 목록을 출력한다. LoadModule 지시어를 사용하여 동적으로 +읽어들이는 모듈은 출력하지 않는다.
+ +
-L
+ +
지시어 목록을 지시어가 받는 아규먼트와 지시어 사용장소와 +같이 출력한다.
+ +
-S
+ +
설정파일에서 읽어들인 설정을 보여준다 (현재는 가상호스트 +설정만을 보여준다).
+ +
-t
+ +
설정파일의 문법검사만 한다. 프로그램은 문법을 검사한후 +(문법이 올바른 경우) 0이나 (문법에 문제가 있는 경우) 0이 아닌 +종료코드로 즉시 종료한다. -D DUMP_VHOSTS을 +사용하면 가상호스트 설정을 자세히 출력한다.
+ +
-v
+ +
httpd의 버전을 출력하고 종료한다.
+ +
-V
+ +
httpd의 버전과 컴파일 파라미터를 출력하고 +종료한다.
+ +
-X
+ +
디버그 상태로 웹서버를 실행한다. 오직 한 프로세스나 쓰레드로만 +서비스하고, 서버는 콘솔에서 떨어지지 않는다.
+ +
+ +

다음 아규먼트는 Windows +플래폼에서만 사용할 수 있다:

+ +
+ +
-k install|config|uninstall
+ +
아파치를 Windows NT 서비스로 설치한다; 아파치 서비스의 시작 +옵션을 수정한다; 아파치 서비스 설치를 지운다.
+ +
-n name
+ +
아파치 서비스의 name.
+ +
-w
+ +
오류가 발생하면 콘솔창을 열어서 오류문을 보여준다.
+ +
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/httpd.xml.ko b/docs/manual/programs/httpd.xml.ko index 845fbb2284..eb8b4c7856 100644 --- a/docs/manual/programs/httpd.xml.ko +++ b/docs/manual/programs/httpd.xml.ko @@ -1,7 +1,7 @@ - + +서버와 지원 프로그램 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1

서버와 지원 프로그램

+
+

가능한 언어:  en  | + ko 

+
+ +

아파치 웹서버에 포함된 프로그램들이다.

+
+
top
+
+

목록

+ +
+
httpd
+ +
아파치 하이퍼텍스트 전송 프로토콜 서버
+ +
apachectl
+ +
아파치 웹서버 조절 인터페이스
+ +
ab
+ +
아파치 웹서버 성능검사 도구
+ +
apxs
+ +
아파치 확장 도구 (APache eXtenSion tool)
+ +
configure
+ +
소스 트리를 구성한다
+ +
dbmmanage
+ +
basic authentication에 사용할 DBM 형식의 사용자 + 인증파일을 만들고 수정한다
+ +
htdigest
+ +
digest authentication에 사용할 사용자 인증파일을 + 만들고 수정한다
+ +
htpasswd
+ +
basic authentication에 사용할 사용자 인증파일을 만들고 + 수정한다
+ +
logresolve
+ +
아파치 로그파일의 IP-주소를 호스트명으로 변환한다
+ +
rotatelogs
+ +
서버를 죽이지않고 아파치 로그를 순환한다
+ +
suexec
+ +
실행을 위해 사용자를 변경한다 (Switch User For Exec)
+ +
다른 프로그램들
+
manpage가 없는 지원 도구들.
+
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/index.xml.ko b/docs/manual/programs/index.xml.ko index bb9d9cb5d3..7a08f7ea97 100644 --- a/docs/manual/programs/index.xml.ko +++ b/docs/manual/programs/index.xml.ko @@ -1,7 +1,7 @@ - + +logresolve - 아파치 로그파일의 IP-주소를 호스트명으로 + 변환한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

logresolve - 아파치 로그파일의 IP-주소를 호스트명으로 + 변환한다

+
+

가능한 언어:  en  | + ko 

+
+ +

logresolve는 아파치 접근로그파일에 있는 + IP-주소를 찾는 후처리 프로그램이다. 네임서버의 부하를 + 최소화하기위해 logresolve는 내부적으로 해쉬테이블 캐쉬를 + 사용한다. 즉, IP 주소가 로그파일에 처음 나올때만 찾는다.

+ +

표준입력으로 아파치 로그파일을 읽는다. 각 줄의 첫번째 + 항목이 IP 주소이고, 나머지 부분과 공백으로 구분되야 한다.

+
+
+
top
+
+

개요

+ +

logresolve [ -s + filename ] [ -c ] < + access_log > access_log.new

+
top
+
+

옵션

+ +
+ +
-s filename
+ +
통계를 기록할 파일명을 지정한다.
+ +
-c
+ +
logresolve가 몇가지 DNS 검사를 하도록 한다: +IP 주소로 호스트명을 찾은후 그 호스트명으로 다시 IP 주소들을 +찾아서 그중 하나가 원래 주소와 일치하는지 검사한다.
+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/logresolve.xml.ko b/docs/manual/programs/logresolve.xml.ko index a69552b2a4..24210e1cfd 100644 --- a/docs/manual/programs/logresolve.xml.ko +++ b/docs/manual/programs/logresolve.xml.ko @@ -1,7 +1,7 @@ - + +Other Programs - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

Other Programs

+
+

가능한 언어:  en  | + ko 

+
+ +

다음은 간단하여 manpage가 없는, 아파치 웹서버에 포함된 + 지원 프로그램들이다. 자동으로 이들을 설치하지 않는다. + 구성과정후 support/ 디렉토리에서 이 프로그램들을 + 찾을 수 있다.

+
+
+
top
+
+

log_server_status

+

이 perl 스크립트는 cron 등에서 자주 실행하도록 설계되었다. + 이 스크립트를 서버에 연결하여 상태 정보를 다운로드한다. + 그런후 이 정보를 한줄로 정리하여 파일에 기록한다. 로그파일의 + 위치를 지정하려면 스크립트 앞부분의 변수를 수정한다.

+
top
+
+

split-logfile

+

이 perl 스크립트는 결합된 웹서버 접근로그파일의 내용을 + 여러 파일로 나눈다. 각 줄의 첫번째 항목이 ("%v"로 + 추가한) 가상호스트 정보이고, 로그파일명은 현재 디렉토리에 + 가상호스트명 + ".log"라고 가정한다.

+ +

결합된 로그파일을 표준입력으로 읽는다. 읽은 내용을 기존의 + 로그파일들에 추가한다.

+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/other.xml.ko b/docs/manual/programs/other.xml.ko index 221dd3d000..053c2dbee6 100644 --- a/docs/manual/programs/other.xml.ko +++ b/docs/manual/programs/other.xml.ko @@ -1,7 +1,7 @@ - + +rotatelogs - 아파치 로그를 순환하기위해 파이프로 연결할 + 로그 프로그램 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

rotatelogs - 아파치 로그를 순환하기위해 파이프로 연결할 + 로그 프로그램

+
+

가능한 언어:  en  | + ko 

+
+
이 문서는 최신판 번역이 아닙니다. + 최근에 변경된 내용은 영어 문서를 참고하세요.
+ +

rotatelogs는 아파치의 파이프 로그파일 기능을 + 위한 간단한 프로그램이다. 예를 들어:

+ +

+ CustomLog "|bin/rotatelogs /var/logs/logfile 86400" common +

+ +

그러면 /var/logs/logfile.nnnn 파일을 만든다. nnnn은 + 로그를 시작한 시스템시간이다 (이 시간은 항상 순환기간의 + 배수이다. 그래서 cron 스크립트로 처리하기 쉽다). 순환기간 + (여기서는 24 시간) 마다 새로운 로그를 시작한다.

+ +

+ CustomLog "|bin/rotatelogs /var/logs/logfile 5M" common +

+ +

이 설정은 로그파일 크기가 5 메가바이트가 될때마다 + 순환한다.

+ +
+
+
top
+
+

개요

+ +

rotatelogs logfile + [ rotationtime [ offset ]] | + [ filesizeM ]

+
top
+
+

옵션

+ +
+ +
logfile
+ +
로그파일의 경로와 이름. logfile에 '%' 문자가 +있다면 strftime(3)의 형식문자열과 같이 처리한다. +'%' 문자가 없다면 뒤에 초단위 시간 .nnnnnnnnnn을 +자동으로 붙인다. 두 형식 모두 현재 기간부터 시작시간을 계산한다.
+ +
rotationtime
+ +
로그파일을 순환할 초단위 시간.
+ +
offset
+ +
UTC에서 분단위 시간차이. 생략하면 0으로 가정하여 UTC를 +사용한다. 예를 들어, UTC -5 시간대의 지역시간을 사용한다면 +아규먼트로 -300을 지정한다.
+ +
filesizeM
+ +
시간이 아닌 크기를 지정할때 메가바이트단위 최대 파일크기 +뒤에 M을 붙인다. rotationtime과 offset 대신 이 +파라미터를 사용한다.
+
+
top
+
+

포팅가능성

+ +

다음 로그파일 형식문자열 표현은 모든 strftime(3) +구현이 지원해야 한다. 라이브러리 특유의 확장은 +strftime(3) manpage를 참고하라.

+ + + + + + + + + + + + + + + + + + + + + + + +
%A(지역화된) 완전한 요일 이름
%a(지역화된) 3-문자 요일 이름
%B(지역화된) 완전한 달 이름
%b(지역화된) 3-문자 달 이름
%c(지역화된) 날짜와 시간
%d2-자리 일
%H2-자리 시간 (24 시간 시계)
%I2-자리 시간 (12 시간 시계)
%j3-자리 날짜수
%M2-자리 분
%m2-자리 달
%p(지역화된) 12 시간 시계의 am/pm
%S2-자리 초
%U2-자리 주일수 (주의 첫번재 날은 +일요일)
%W2-자리 주일수 (주의 첫번재 날은 +월요일)
%w1-자리 요일수 (주의 첫번째 날은 +일요일)
%X(지역화된) 시간
%x(지역화된) 날짜
%Y4-자리 연도
%y2-자리 연도
%Z시간대 이름
%%문자그대로 `%'
+ +
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/rotatelogs.xml.ko b/docs/manual/programs/rotatelogs.xml.ko index fdf8cf0a78..fd7780446a 100644 --- a/docs/manual/programs/rotatelogs.xml.ko +++ b/docs/manual/programs/rotatelogs.xml.ko @@ -1,7 +1,7 @@ - + +suexec - 외부 프로그램을 실행하기 전에 사용자를 변경한다 - Apache HTTP Server + + + + +
+

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

+

Apache HTTP Server Version 2.1

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.1 > Programs

suexec - 외부 프로그램을 실행하기 전에 사용자를 변경한다

+
+

가능한 언어:  en  | + ko 

+
+ +

아파치 웹서버는 CGI 프로그램을 실행하기 전에 다른 사용자로 + 전환하기위해 suexec를 사용한다. 이를 사용하려면 + 서버를 root 계정으로 실행해야 한다. 보통 웹 + 데몬을 root 계정으로 실행하지 않기때문에 + suexec 실행파일에 setuid 비트를 설정하고 + root가 소유주이어야 한다. root이외의 + 다른 사용자가 쓰기권한을 가지면 안된다.

+ +

suexec의 개념과 보안모델에 대한 정보는 suexec 문서를 + (http://httpd.apache.org/docs-2.1/suexec.html) 참고하라.

+
+
+
top
+
+

개요

+

suexec -V

+
top
+
+

옵션

+ +
+
-V
+ +
root가 실행하면 suexec의 컴파일 +옵션을 출력한다. 보안상 이유로 모든 설정옵션은 컴파일할 때만 +지정할 수 있다.
+ +
+
+
+

가능한 언어:  en  | + ko 

+
+ \ No newline at end of file diff --git a/docs/manual/programs/suexec.xml.ko b/docs/manual/programs/suexec.xml.ko index 9c34e36c57..e9037051fd 100644 --- a/docs/manual/programs/suexec.xml.ko +++ b/docs/manual/programs/suexec.xml.ko @@ -1,7 +1,7 @@ - +