SSL 인증서 만료일 확인하기

리눅스/APACHE|2018. 11. 30. 15:06
반응형

# openssl x509 -in /ssl/file.crt -noout -text



반응형

댓글()

Apache 설치 후 WEB 403 Forbidden 에러

리눅스/APACHE|2018. 11. 14. 16:08
반응형

# Apache 를 Source 컴파일 한 이후에 브라우저에서

URL 혹은 IP 를 치고 들어가면 403 Forbidden 에러가 발생하는 경우가 있습니다.


# 조치 방법

컴파일을 한 위치의 httpd.conf 파일을 찾습니다. (ex : /usr/local/apache2/conf/httpd.conf)


파일내용 중


<Directory />

    AllowOverride None

    Require all granted (denied를 granted로 수정)

</Directory>


위와 같이 수정하고 graceful 또는 restart 합니다.

반응형

댓글()

mod_rewrite 로 리다이렉트 (redirect) 하기 / 포워딩

리눅스/APACHE|2017. 6. 8. 11:57
반응형

httpd.conf 의 Directory 옵션에서 .htaccess 파일 사용 허용되어있는지 보고

DocumentRoot 디렉토리에 아래 파일을 만들면 됩니다.



[root@sysdocu public_html]# vi .htaccess


<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www.sysdocu.kr$

RewriteRule (.*) https://www.sysdocu.kr%{REQUEST_URI} [L,R=301]

</IfModule>


* 설명 접속주소가 www.sysdocu.kr 이 아닌 경우 https://www.sysdocu.kr 로 포워딩하며 뒤에 요청 주소도 같이 따라오도록한다.


반응형

댓글()

특정 파일이 소속된 rpm 패키지 찾기

리눅스/APACHE|2017. 3. 6. 11:20
반응형

특정 파일이 어떤 rpm 패키지에 소속 되어 있는지 찾고 싶을 때

 

예를 들어, df 라는 명령어(파일)가 어떤 패키지에 포함 되어 있는지 알고 싶다면,

 

1. 우선 df의 경로를 알아낸 뒤

[root@localhost ~]# which df
/bin/df

2. rpm -qf 명령으로 해당 파일의 경로를 적어 준다

[root@localhost ~]# rpm -qf /bin/df
coreutils-5.97-34.el5_8.1



[출처] http://faq.hostway.co.kr/Linux_ETC/4416

반응형

댓글()

APACHE 2.4 + PHP 5.5 + MYSQL 5.6 설치

리눅스/APACHE|2017. 1. 2. 11:07
반응형

설치 버전

  • apache-2.4.xx
  • php-5.5.xx
  • mysql-5.6.xx

MySQL 설치

Note : MySQL 소스컴파일 설치하는 과정에 대한 내용이며, 설치 버전은 mysql-5.6의 가장 최신 버전을 사용한다.

mysql user 생성

소스코드 다운로드
Download

다운받은 소스 파일 압축 해제

필요한 패키지 설치

Note : 설치에 앞서 필요한 패키지를 다운로드 한다.

설치

설정파일 복사

시작 스크립트 복사

Note : 부팅시 자동으로 시작 할 수 있게 하기 위해 init 스크립트를 /etc/rc.d/init.d/로 복사한다.

기본 데이터베이스 생성

데이터베이스 구동

root 패스워드 설정

OR


Apache 설치

Note : 다음은 Apache 소스컴파일 과정이며, 설치 버전은 apache-2.4의 가장 최신 버전을 사용한다.

필요한 패키지 설치

Note : 설치 패키지 내용은 시스템 환경 마다 다소 차이가 있을 수 있다.

apache 소스 압축 해제

아파치 소스에 apr 추가

Note : apr 소스 복사 기존 httpd-2.2 소스에는 aprapr-util 이 포함되 어있었는데 2.4 버전에서 부터는 포함이 되어 있지 않아 수동으로 포함 시켜줘야 하는 번거로움이 있다.

컴파일

시작 스크립트 복사

구동 스크립트 복사후 아래 내용 추가

/etc/rc.d/init.d/httpd 파일의 최상단에 다음내용을 추가.

서비스 등록


PHP 설치

Note : 다음 내용은 PHP 소스컴파일 과정에 대한 내용이며, 설치 버전은 php-5.5의 가장 최신버전을 사용한다.

소스파일 압축 해제

필요한 패키지 설치

컴파일

Note : 컴파일 옵션은 그닥 별다른 사항은 없으나, mysql 연동하는 부분에서 mysqlnd를 사용했다.
mysqlnd를 사용한 이유는 기존 php mysql 연동시 mysql client library를 통해 연동을 했으나 mysql client library를 설치 하지 않아도 mysql 연동이 가능하고, php확장 모듈로 만들어졌기 때문에 php동작과 긴밀하게 연결되어 있어 메모리 관리 측면에서 효율적이다. 또한 mysqlnd는 여러기능의 플러그인을 지원한다.
mysqlnd에 대한 자세한 내용은 http://php.net/manual/kr/intro.mysqlnd.php에서 확인 가능하다.

환경설정 파일 복사

아파치 환경 설정

httpd.conf 파일에 다음 내용 추가 및 수정

연동 확인
/usr/local/apache/htdocs/info.php 파일을 만들어 아래 내용을 삽입 후 저장.

웹브라우져에서 http://ip-address/info.php 호출해 php information 페이지가 잘 출력되면 성공적으로 설치된 것이다.



[출처] https://blog.onlab.kr/2016/07/29/apache-2-4-php-5-5-mysql-5-6-%EC%84%A4%EC%B9%98/

반응형

댓글()

mod_perl + apache2 연동

리눅스/APACHE|2016. 4. 27. 15:38
반응형

mod_perl 2.0.4 받아서 설치한다.
다운로드는 http://apache.perl.org/download/index.html

# tar -xvzf mod_perl-2.x.xx.tar.gz
# cd modperl-2.0
# perl Makefile.PL MP_APXS=$HOME/httpd/prefork/bin/apxs
# make && make test && make install


httpd.conf 수정

LoadModule perl_module modules/mod_perl.so


vhosts.conf 수정

  <Location /사용하고자하는 디렉토리>
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options ExecCGI
    allow from all
    PerlSendHeader On
  </Location>


전체 설정에서 pl 파일 만 적용하고 싶다면...

  <Directory /home/>
    <FilesMatch "\.(pl)$">
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options ExecCGI
    allow from all
    PerlSendHeader On
    </FilesMatch>
  </Directory>




[출처] http://onlybible.tistory.com/1650

반응형

댓글()

버전별 다운로드 (Apache, PHP, MySQL, JDK, Tomcat, Curl)

리눅스/APACHE|2015. 11. 30. 10:57
반응형

[ 아파치 ]
https://archive.apache.org/dist/httpd/


[ PHP ]
리눅스
http://mirror.cogentco.com/pub/php/
https://secure.php.net/releases/
https://museum.php.net/ (추천)
윈도우즈
http://windows.php.net/downloads/releases/archives/


[ MySQL ]
http://ftp.kaist.ac.kr/mysql/Downloads/
http://downloads.mysql.com/archives.php


[ JDK ]
http://monalisa.cern.ch/MONALISA/download/java/


[ Tomcat ]
http://archive.apache.org/dist/tomcat/


[ Curl ]
https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/www/utilities/curl/
https://curl.haxx.se/download/

반응형

댓글()

mod_rewrite 룰 설정에 대한 자세한 설명

리눅스/APACHE|2015. 1. 16. 17:11
반응형

원문 URL: http://httpd.apache.org/docs/2.4/en/rewrite/intro.html#rewriterule


Apache 서버의 .htaccess에 사용되는 URL Rewrite에 대한 자료를 찾다 답답해서 아싸리 그냥 Apache 공식 사이트에 설명된 자료를 퍼와서 번역을 했다. (본 문서의 번역은 의역성이 매우 강하니 혹시라도 이 글을 참고하시는 분은 반드시 이 부분을 감안하여 읽어주시기 바랍니다.) 



Apache mod_rewrite Introduction

아파치 mod_rewrite 소개

This document supplements the mod_rewrite reference documentation. It describes the basic concepts necessary for use of mod_rewrite. Other documents go into greater detail, but this doc should help the beginner get their feet wet.


이 문서는 mod_rewrite 레퍼런스 문서에 대한 보충물이다. 이 문서는 mod_rewrite의 사용에 필요한 기본 개념을 설명한다. 다른 문서들은 보다 세부적인 내용을 다루지만 이 문서는 초보자에게 mode_rewrite에 대한 맛을(?) 볼 수 있게 도와줄 것이다. 


top


Introduction (소개)

The Apache module mod_rewrite is a very powerful and sophisticated module which provides a way to do URL manipulations. With it, you can do nearly all types of URL rewriting that you may need. It is, however, somewhat complex, and may be intimidating to the beginner. There is also a tendency to treat rewrite rules as magic incantation, using them without actually understanding what they do.


아파치 모듈인 mod_rewrite은 URL을 조작(?)할 수 있는 수단을 제공하는 매우 강력하고 섬세한 모듈이다. 이 모듈로 당신이 필요한 거의 모든 타입의 URL rewriting을 할 수 있다. 하지만 이것은 좀 복잡한 편이고 초보자가 처음 다루기에는 부담스러울 수 있다. mod_rewrite가 어떤 일을 하는지에 대한 정확한 이해없이 rewrite 룰을 마치 마법 주문처럼 여기는 경향이 있다.  


This document attempts to give sufficient background so that what follows is understood, rather than just copied blindly.


이 문서는 당신이 그냥 별 생각없이 복사하여 붙여넣기 하기 보다는 이후의 내용을 이해할 수 있게 충분한 백그라운드를 제공하려 한다.  


Remember that many common URL-manipulation tasks don't require the full power and complexity of mod_rewrite. For simple tasks, see mod_alias and the documentation on mapping URLs to the filesystem.


보통 대다수의 URL을 조작하는 일은 mod_rewrite 모듈이 가진 모든 능력과 그 복잡함을 필요료 하지 않는다. (의역: 실제 사용되는 대다수의 URL 조작은 단순한 편이고 그 패턴이 정해져있다.) 단순한 조작에 대한 설명은 mod_alias 와 mapping URLs to the filesystem (파일 시스템에 URL 패핑하기)에 있는 문서를 참고하라. 


Finally, before proceeding, be sure to configure mod_rewrite's log level to one of the trace levels using the LogLevel directive. Although this can give an overwhelming amount of information, it is indispensable in debugging problems with mod_rewrite configuration, since it will tell you exactly how each rule is processed.


먼저 mod_rewrite의 log 레벨을 반드시 LogLevel 지침을 사용하는(사용하여?) trace 레벨 중 하나로 설정하라. 이렇게 하면 비록 어마어마한 양의 로그 정보를 생산할 수 있지만 이렇게 함으로써 정확히 어떤 룰이 실행되는지를 알려주기 때문에 mod_rewrite 설정과 관련된 문제를 디버깅하는데 필수적이라 할 수 있다. 


Regular Expressions (정규 표현식)

mod_rewrite uses the Perl Compatible Regular Expression vocabulary. In this document, we do not attempt to provide a detailed reference to regular expressions. For that, we recommend the PCRE man pages, the Perl regular expression man page, and Mastering Regular Expressions, by Jeffrey Friedl.


mod_rewrite는 Perl Compatible Regular Expression(Perl과 호환하는 정규 표현식) 어휘를 사용한다. 이 문서에서는 정규 표현식과 관련된 디테일한 내용을 다루지 않기 때문에 정규 표현식에 대한 세부내용은 PCRE man pagesPerl regular expression man page, 그리고 Mastering Regular Expressions, by Jeffrey Friedl.을 추천한다. 


In this document, we attempt to provide enough of a regex vocabulary to get you started, without being overwhelming, in the hope that RewriteRules will be scientific formulae, rather than magical incantations.


 RewriteRule이 마법 주문이 아닌 과학적인 공식이라는 것을 알았으면 하는 바램에서 이 문서에서는 당신이 시작하기에 충분한 regex (정규표현식) 어휘들를 제공할 것이다. 


Regex vocabulary (정규표현식 어휘)

The following are the minimal building blocks you will need, in order to write regular expressions and RewriteRules. They certainly do not represent a complete regular expression vocabulary, but they are a good place to start, and should help you read basic regular expressions, as well as write your own.


아래는 당신이 정규 표현식과 RewriteRule을 사용할 수 있는데에 필요한 최소한의 구성 요소이다. 물론 아래의 구성 요소는 정규 표현식의 모든 어휘를 포함하는 것은 절대 아니지만 최소한 당신이 기초적인 정규 표현식을 읽을 수 있고 또한 직접 작성할 수 있게 도와줄 첫 걸음이 될 것이다. 

Character

(문자)

Meaning
(의미)
Example
(예제)
.

Matches any single character
(아무 단일 문자에 상응한다)

c.t will match catcotcut, etc.
(c.t는 cat, cot, cut 등에 상응한다.)  
+Repeats the previous match one or more times
(문자가 한 번 또는 그 이상 상응함을 나타낸다)

a+ matches aaaaaa, etc
(a+는 a, aa, aaa등에 상응한다)
*Repeats the previous match zero or more times.
(문자가 0번 혹은 그 이상 상응함을 나타낸다)

a* matches all the same things a+ matches, but will also match an empty string.
(a*는 a+에 상응하는 모든 문자에 상응하고 또한 빈 문자에도 상응한다)

?Makes the match optional.
(선택적 상응을 나타낸다. 즉, 있어도 되고 없어도 됨)

colou?r will match color and colour.
(colou?r는 color와 colour에 상응한다)
^Called an anchor, matches the beginning of the string
(앵커라고 불리우며 스트링의 시작을 나타낸다)

^a matches a string that begins with a
(^a는 a로 시작하는 스트링에 상응한다)
$The other anchor, this matches the end of the string.
(스트링의 끝을 나타내는 또 다른 앵커)

a$ matches a string that ends with a.
(a$는 a로 끝나는 스트링에 상응한다)
( )

Groups several characters into a single unit, and captures a match for use in a backreference.
(다수의 문자들을 하나의 유닛으로 묶는다. 역참조시 매칭되는 부분을 Substition(대체) 변수에 담긴다.)

(ab)+ matches ababab - that is, the + applies to the group. For more on backreferences see below.
( (ab)+는 ababab에 상응한다. 이 말은 +가 묶음에 적용된다는 뜻이다. backreference에 대한 설명은 아래 참고)
[ ]

A character class - matches one of the characters
(문자 클래스 - 문자들 중 하나에 상응한다. 즉, []안에 있는 문자들 중 하나라도 있으면 상응함)

c[uoa]t matches cutcot or cat.
( c[uoa]t 는 cut, cot, cat에 상응한다)
[^ ]

Negative character class - matches any character not specified
(부정 문자 클래스 - 설정되지 않은 문자에 상응한다. 즉, ^뒤에 지정된 문자가 아니면 상응함)

c[^/]t matches cat or c=t but not c/t
( c[^/]는 cat이나 c=t에 상응하지만 c/t에는 상으하지 않는다)

In mod_rewrite the ! character can be used before a regular expression to negate it. This is, a string will be considered to have matched only if it does not match the rest of the expression.


mod_rewrite에서 ! 문자는 정규식 앞에 사용되면 부인한다는(반대된다는) 의미이다. 즉, 스트링이 정규식에 상응하지 않을 때 정규식 앞에 !을 붙임으로써 상응하게 되게 것이다. 


Regex Back-Reference Availability (정규표현식 Back-Reference[역참조?] 능력)

One important thing here has to be remembered: Whenever you use parentheses in Pattern or in one of the CondPattern, back-references are internally created which can be used with the strings $N and %N (see below). These are available for creating the strings Substitution and TestString as outlined in the following chapters. Figure 1 shows to which locations the back-references are transferred for expansion as well as illustrating the flow of the RewriteRule, RewriteCond matching. In the next chapters, we will be exploring how to use these back-references, so do not fret if it seems a bit alien to you at first.


여기서 반드시 기억해야 할 아주 중요한 사항 한 가지! : Pattern(패턴)이나 CondPattern(조건 패턴?)에서 둥근 괄호를 사용할 때, $N, %N 스트링과 함께 사용될 수 있는 역 참조가 내부적으로 생성이 된다. (아래 참고) 이것은 다음 챕터에 설명되는 Substitution(대체) 스트링과 TestString을 생성할 때 사용될 수 있다. 그림 1은 RewriteRule, RewriteCond 매칭의 흐름에 대해서 묘사하고 있고 또한 확장(expansion)? 을 위해 역 참조가 이동하는 위치를 보여주고 있다. 다음 챕터에서 이 역참조를 사용하는 방법에 대해서 더 배울테니 처음 보고 생소하더라도 쫄지마라. 


Flow of RewriteRule and RewriteCond matching
Figure 1: The back-reference flow through a rule.
In this example, a request for /test/1234 would be transformed into /admin.foo?page=test&id=1234&host=admin.example.com.

(그림 1: 룰을 통한 역 참조의 흐름. 이 예제에서는 /test/1234에 대한 리퀘스트가 /admin.foo?page=test&id=1234&host=admin.example.com.으로 변환된다.)



RewriteRule Basics (RewriteRule 기초)

RewriteRule consists of three arguments separated by spaces. The arguments are

RewriteRule은 아래와 같이 공백(스페이스)로 구분되어진 3개의 인자로 구성된다. 

  1. Pattern: which incoming URLs should be affected by the rule;
  2. Substitution: where should the matching requests be sent;
  3. [flags]: options affecting the rewritten request.
1. 패턴: 룰에 의해서 변경되어질 입력 URL
2. 대체: 어떻게 재작성될지에 대한 정의
3. 신호: 재작성된 리퀘스트에 영향을 행사하는 옵션 

The Pattern is a regular expression. It is initially (for the first rewrite rule or until a substitution occurs) matched against the URL-path of the incoming request (the part after the hostname but before any question mark indicating the beginning of a query string) or, in per-directory context, against the request's path relative to the directory for which the rule is defined. Once a substitution has occurred, the rules that follow are matched against the substituted value.


여기서 패턴은 정규표현식이다. 이 정규 표현식은 입력 리퀘스트(hostname 뒤에 오고 쿼리 스트링을 나타내는 물음표는 전에 오는 부분)의 URL 경로에 상응하거나 혹은 디렉토리별 컨텍스트에서 룰 정의가 적용된 디렉토리로 들어오는 리퀘스트의 상대적 경로에 해당한다. 일단 대체가 발생하고 나면, 그 뒤의 룰은 대체된 값에 상응하게 된다. 


Syntax of the RewriteRule directive
Figure 2: Syntax of the RewriteRule directive.


       

그림 2: RewriteRule 작성법



The Substitution can itself be one of three things:

Substitution(대체)는 다음 세 개 중 하나가 될 수 있다: 

A full filesystem path to a resource
리소스에 대한 완전한(full) 파일 시스템 경로
RewriteRule ^/games /usr/local/games/web

This maps a request to an arbitrary location on your filesystem, much like the Alias directive.


이것은 리퀘스트(^/games 형식의 정규식. 즉, http://hostname/games 형식임)를 파일시스템에서 임의의 위치로 (여기서는 "/usr/local/games/web"  매핑한다. Alias 명령이랑 매우 유사하다. 

A web-path to a resource
리소스에 대한 웹 경로
RewriteRule ^/foo$ /bar

If DocumentRoot is set to /usr/local/apache2/htdocs, then this directive would map requests for http://example.com/foo to the path/usr/local/apache2/htdocs/bar.


만약 DocumentRoot 가 /usr/local/apache2/htdocs로 설정되었다면 이 명령은 http://example.com/foo으로 들어오는 리퀘스트를 으/usr/local/apache2/htdocs/bar로 매핑한다. 

An absolute URL
절대 URL
RewriteRule ^/product/view$ http://site2.example.com/seeproduct.html [R]

This tells the client to make a new request for the specified URL.


이 명령은 클라이언트에게 지정된 URL로 새로운 리퀘스트를 보내라고 통보한다. 

The Substitution can also contain back-references to parts of the incoming URL-path matched by the Pattern. Consider the following:


Substitution(대체)는 Pattern(패턴)에 매칭되는 입력 URL 경로의 부분에 대한 역 참조를 포함할 수 있다. 

RewriteRule ^/product/(.*)/view$ /var/web/productdb/$1

The variable $1 will be replaced with whatever text was matched by the expression inside the parenthesis in the Pattern. For example, a request for http://example.com/product/r14df/view will be mapped to the path /var/web/productdb/r14df.


$1 변수는 패턴의 괄호 안의 정규식에 매칭되는 텍스트로 교체된다.  예를 들어, http://example.com/product/r14df/view에 대한 리퀘스트는 /var/web/productdb/r14df.의 경로로 매핑된다. 


If there is more than one expression in parenthesis, they are available in order in the variables $1$2$3, and so on.


만약 괄호안에 하나 두 개 이상의 정규식이 존재한다면 이들은 $1$2$3.. 형식으로 사용 가능하다. 


top

Rewrite Flags (Rewrite 신호)

The behavior of a RewriteRule can be modified by the application of one or more flags to the end of the rule. For example, the matching behavior of a rule can be made case-insensitive by the application of the [NC] flag:


룰 끝에 하나 혹은 그 이상의 신호를 추가함으로써 RewriteRule의 작동 방식을 수정할 수 있다. 예를 들어, 룰의 매칭 방식을 [NC] 신호를 사용하여 대소문자 구분을 안 하게 할 수 있다. (NC는 Non Case-sensitive의 약자인듯)

RewriteRule ^puppy.html smalldog.html [NC]

For more details on the available flags, their meanings, and examples, see the Rewrite Flags document.


신호에 대한 좀 더 구체적인 정보와 예제는 Rewrite Flags 문서를 참고하라.  


top

Rewrite Conditions (Rewrite 조건)

One or more RewriteCond directives can be used to restrict the types of requests that will be subject to the following RewriteRule. The first argument is a variable describing a characteristic of the request, the second argument is a regular expression that must match the variable, and a third optional argument is a list of flags that modify how the match is evaluated.


하나 혹은 그 이상의 RewriteCond 명령은 이 명령 다음에 오는 RewriteRule에 대한 리퀘스트 타입을 제한하는데 사용될 수 있다. 첫번째 인자는 리퀘스트의 특징을 묘사하는 변수이고, 두번째 인자는 이 변수에 매칭되어야 하는 정규표현식이다. 그리고 세번째 인자(선택사항임)는 매칭이 어떻게 처리되어야 하는지에 대해 수정하는 신호 목록이다.(?)

Syntax of the RewriteCond directive
Figure 3: Syntax of the RewriteCond directive


그림 3: RewriteCond 명령의 작성법

For example, to send all requests from a particular IP range to a different server, you could use:


예를 들어, 특정 IP 영역대에서 들어오는 모든 리퀘스트들을 다른 서버로 보내고 싶다면 아래와 같이 할 수 있다: 

RewriteCond %{REMOTE_ADDR} ^10\.2\.
RewriteRule (.*) http://intranet.example.com$1

When more than one RewriteCond is specified, they must all match for the RewriteRule to be applied. For example, to deny requests that contain the word "hack" in their query string, unless they also contain a cookie containing the word "go", you could use:


RewriteCond이 두 개 이상 선언됐을때, 이들은 모두 RewriteRule에 매칭되어야 한다. 예를 들어, 쿼리 스트링에 "hack"이라는 단어를 포함한 리퀘스트들을 거부하려면 ("go"라는 단어를 포함하는 쿠키를 포함하지 않는 이상) 아래와 같이 할 수 있다. 

RewriteCond %{QUERY_STRING} hack
RewriteCond %{HTTP_COOKIE} !go
RewriteRule . - [F]

Notice that the exclamation mark specifies a negative match, so the rule is only applied if the cookie does not contain "go".


느낌표는 부정을 의미하기 때문에 여기서는 쿠키가 "go"를 포함하지 않을 때에만 룰이 적용된다. 


Matches in the regular expressions contained in the RewriteConds can be used as part of the Substitution in the RewriteRule using the variables %1%2, etc. For example, this will direct the request to a different directory depending on the hostname used to access the site:


RewriteConds 에 포함된 정규식에 대한 매칭은 RewriteRule 에서 %1%2,.. 변수를 이용하여 대체구문(Substitution)의 부분으로 사용될 수 있다. 예를 들어, 아래는 사이트 접속에 사용된 hostname에 따라 다른 디렉토리로 리퀘스트를 보낸다. 

RewriteCond %{HTTP_HOST} (.*)
RewriteRule ^/(.*) /sites/%1/$1

If the request was for http://example.com/foo/bar, then %1 would contain example.com and $1 would contain foo/bar.


만약 리퀘스트가 http://example.com/foo/bar 이라면 %1는 example.com이 되고 $1는 foo/bar가 된다. 


top

Rewrite maps (Rewrite 매핑)

The RewriteMap directive provides a way to call an external function, so to speak, to do your rewriting for you. This is discussed in greater detail in the RewriteMap supplementary documentation.


RewriteMap  명령은 rewriting을 해주는 외부 함수를 호출할 수 있는 수단을 제공한다. 세부내용은 RewriteMap supplementary documentation. 참고하기 바란다. 


top

.htaccess files (.htaccess 파일)

Rewriting is typically configured in the main server configuration setting (outside any <Directory> section) or inside <VirtualHost> containers. This is the easiest way to do rewriting and is recommended. It is possible, however, to do rewriting inside <Directory> sections or .htaccess files at the expense of some additional complexity. This technique is called per-directory rewrites.


Rewriting은 보통 메인 서버 구성 설정(<Directory> 섹셕 밖 아무데나)이나  <VirtualHost> 컨테이너에 구성이 된다. 이 방법은 가장 쉬운 방법이고 또한 권장사항이기도 하다. 그러나 약간 복잡하긴 하지만 <Directory>  섹션 안에 혹은 .htaccess 파일에 rewriting이 가능하다. 이 기술은 "디렉토리별 rewrite" (per-directory rewrites)라 불린다. 


The main difference with per-server rewrites is that the path prefix of the directory containing the .htaccess file is stripped before matching in the RewriteRule. In addition, the RewriteBase should be used to assure the request is properly mapped.


디렉토리별 rewrite를 사용했을 때의 가장 다른 점은 .htaccess 파일을 포함하는 디렉토리에 대한 경로 prefix가 RewriteRule에서 매칭되기 전에 제거가 된다는 것이다. 또한, 리퀘스트가 올바르게 매핑되었다는 것을 확실히 하기 위해  RewriteBase가 사용되어야 한다.  


[출처] 파노카페 (http://panocafe.tistory.com/708)

반응형

댓글()

특정 확장자 <a> 링크 무조건 다운받게 하기

리눅스/APACHE|2015. 1. 16. 17:10
반응형

.htaccess 파일을 만들어 아래 내용을 넣고 FTP로 업로드 폴더에 넣으면 된다.

<FilesMatch "\.(?i:doc|odf|pdf|rtf|txt)$">
  Header set Content-Disposition attachment
</FilesMatch>

위처럼 하면 doc, odf, pdf, rtf, txt 파일을 브라우저가 보여 주지 않고 다운로드 받게 한다.

물론 꼭 이렇게까지 해야 하나 싶긴 하다. 브라우저에서 PDF를 보는 게 특별히 나쁘다고 생각하지 않기 때문이다. 사용자들도 그리 당황하지 않는다고 본다. 사용자들은 뒤로 가기 기능을 아주 잘 이해하고 있으니 말이다. 이제는 저장 기능도 나름대로 잘 사용하고.

물론 저장하는 걸 못해서 당황하는 사용자들도 좀 있을 텐데, PDF를 브라우저가 바로 보여 주게 된 지 꽤 돼서 이것도 많이 좋아지지 않았나 싶다. 이상.

[출처] 웹으로 말하기 (http://mytory.net/archives/10490)



반응형

댓글()

아파치 2.3.x / 2.4.x mod_url 설치

리눅스/APACHE|2015. 1. 16. 17:03
반응형
아파치 최신 버전은 새로운 mod_url 모듈로 설치해야 합니다.
설치 방법은 아래와 같습니다.
(아파치 2.2 이하 버전은 별도의 게시물을 확인해주세요.)

1. 설치
[root@sysdocu ~]# cd /usr/local/src
[root@sysdocu src]# bunzip2 mod_url-apache2-1.6.2.6.tar.bz2
[root@sysdocu src]# tar xvf mod_url-apache2-1.6.2.6.tar
[root@sysdocu src]# cd mod_url-apache2
[root@sysdocu mod_url-apache2]# /usr/local/apache/bin/apxs -cia mod_url.c

2. 설정
아파치 설정파일 (httpd.conf) 을 열어 아래 내용을 추가(또는 확인)합니다.

LoadModule redurl_module      modules/mod_url.so

<IfModule mod_url.c>
CheckURL On

ServerEncoding EUC-KR

ClientEncoding UTF-8

</IfModule> 


3. 적용

아파치를 재시작 해줍니다.

[root@sysdocu ~]# /usr/local/apache/bin/apachectl restart



mod_url.c



반응형

댓글()

웹서버 TIME_WAIT 많을 시 대처 방법

리눅스/APACHE|2015. 1. 16. 17:02
반응형

네트워크 관련 프로그램이 TIME-WAIT이 걸린경우가 너무 많아 문제가 될경우에...

netstat 로 확인할때 status가 TIME-WAIT이 걸린것이 있다는것은 packet이 정상적으로 host & client가 종료를 한것이고 host에서는 다음 네트워크 신호가 올때 빠르게 연결하여 사용할수 있도록 약 (linux default 60sec) 1분정도 TIME-WAIT status로 대기하고 있다.

 

만약에 TIME-WAIT이 있다면 이것은 하나의 port를 잡고 있는것이므로 너무 많은 TIME-WAIT이 있으면 나중에 network port 부족으로 더이상 창이 뜨지도 않고 문제가될경우도 있다.

 

이럴경우 이 TIME-WAIT을 오랜시간 기다리지 않고 바로바로 socket를 닫아버리게 설정하려면 우선은 /etc/sysctl.conf 파일에서 timeout_time_wait, timeout_close_wait, timeout_fin_wait 값을 조절해주면 된다.

그러나 시스템에 따라서는 이것을 조절해줘도 해결이 안되는 경우가 있다.

 

이럴경우에 kernel에 time-wait에 대한 세션 recycle을 강제로 진행하도록 해준다.

그러면 time-wait가 걸리지 않는다.

 

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle


[출처] 웹서버 TIME_WAIT 많을 시 대처 방법|작성자 백가이다

반응형

댓글()