Mulitple Queues

리눅스/Mail|2015. 1. 23. 09:03
반응형

/etc/mail/sendmail.cf 를 열고 QueueDirectory 라는 문자열이 들어 있는 라인을 찾는다. 그리고 아래와 같이 되어 있다면 그냥 넘어 가고 다르다면 아래와 같이 수정을 해 준다.

다음 위의 경로로 이동을 하여 /var/spool/mqueue 에 sub directory가 없다면 q1~q6 까지의 Directory를 만들어 주도록 한다. 그리고 sendmail을 재시작 하면 된다.


[출처] http://blog.naver.com/legendon/140013722592


반응형

댓글()

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 많을 시 대처 방법|작성자 백가이다

반응형

댓글()

리눅스 동영상 스트리밍 모듈 설치 (mod_h264_streaming)

리눅스/APACHE|2015. 1. 16. 17:02
반응형
아파치 웹서버에 모듈 하나만 올리면 바로 사용이 가능합니다.
(httpd 2.2.17 버전에서 확인)

1. 설치
# cd /usr/local/src
# tar xvzf apache_mod_h264_streaming-2.2.7.tar.gz
# cd mod_h264_streaming-2.2.7
# ./configure --with-apxs=/usr/local/apache/bin/apxs
# make
# make install

2. 설정
아파치 설정 파일 (httpd.conf)에 아래 행을 추가해줍니다.
LoadModule h264_streaming_module modules/mod_h264_streaming.so

AddHandler h264-streaming.extensions .mp4 


apache 를 재시작하여 설정을 적용합니다.
# /usr/local/apache/bin/apachectl restart

3. 확인
동영상 파일을 홈페이지에 올려놓고 아래 처럼 접속하여 확인합니다.


반응형

댓글()

아파치 2.2.x + 톰캣 7.0.x 연동하기

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

아파치 및 PHP 는 설치되어있다는 가정하에 설명합니다.

jdk 및 tomcat 은 작성일자 (2013. 10. 08) 최신버전입니다.

 

[설치 버전]

http 2.2.17

jdk 1.7.0_40

tomcat 7.0.42

 

 

1. jdk 다운로드 및 설치

http://java.sun.com 사이트의 'Java SE' 메뉴에서 최신버전의 JDK를 다운로드 받아 서버에 올려놓습니다.

올려놓은 파일을 rpm 명령어로 설치합니다.

 

# rpm -Uvh jdk-7u40-linux-x64.rpm

 

설치가 완료되었으면 환경변수 설정을 합니다.

 

# vi /etc/profile

JAVA_HOME=/usr/java/jdk1.7.0_40

CATALINA_HOME=/usr/local/tomcat

PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin

 

저장후 적용을 위해 아래 명령을 실행합니다.

# source /etc/profile

 

java가 정상적으로 설치되었는지 버전을 확인해봅니다.

# java -version

 

java version "1.7.0_40"

Java(TM) SE Runtime Environment (build 1.7.0_40-b43)

Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

 

 

2. tomcat 다운로드 및 설치

# cd /usr/local/src

# wget http://apache.tt.co.kr/tomcat/tomcat-7/v7.0.54/bin/apache-tomcat-7.0.42.tar.gz

# tar xvzf apache-tomcat-7.0.42.tar.gz

# mv apache-tomcat-7.0.42 /usr/local/tomcat

 

tomcat 이 정상적으로 설치 되었는지 실행을 통해 확인해봅니다.

# startup.sh

 

Using CATALINA_BASE:   /usr/local/tomcat

Using CATALINA_HOME:   /usr/local/tomcat

Using CATALINA_TMPDIR: /usr/local/tomcat/temp

Using JRE_HOME:        /usr/java/jdk1.7.0_40

Using CLASSPATH:       /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar

 

 

3. mod_jk 설치

연동에 필요한 커넥터를 다운로드 하고 mod_jk.so 파일을 생성합니다.

 

# wget http://apache.tt.co.kr//tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.37-src.tar.gz

# tar xvzf tomcat-connectors-1.2.37-src.tar.gz

cd tomcat-connectors-1.2.37-src/native

# ./buildconf.sh

# ./configure --with-apxs=/usr/local/apache/bin/apxs

# make

# cp -arp apache-2.0/mod_jk.so /usr/local/apache/modules

 

------ 또다른 방법 ----------

연동에 필요한 커넥터를 다운로드 합니다.

OS bit 수 나 아파치의 버전이 틀리다면 아래 URL 에서 파일명을 제외하고 접속한 뒤

사용하는 버전 디렉토리를 찾아가 다운로드를 하면 됩니다.


# wget http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/linux/jk-1.2.31/x86_64/mod_jk-1.2.31-httpd-2.2.x.so

# cp -arp mod_jk-1.2.31-httpd-2.2.x.so /usr/local/apache/modules/mod_jk.so

# chmod 755 /usr/local/apache/modules/mod_jk.so

----------------------------

 

 

4. http + tomcat 연동 설정

아파치 설정 파일을 열어 아파치 구동시 모듈이 불어와지도록 아래 내용을 추가해줍니다.

# vi /usr/local/apache/conf/httpd.conf

LoadModule jk_module modules/mod_jk.so 

 

DirectoryIndex index.html index.htm index.php index.jsp

 

AddType application/x-httpd-php .html .htm .php .inc .jsp

 

<IfModule jk_module>

JkWorkersFile conf/workers.properties

JkShmFile logs/mod_jk.shm

JkLogFile logs/mod_jk.log

JkLogLevel info

JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

</ifModule>


# vi /usr/local/apache/conf/workers.properties

workers.tomcat_home=/usr/local/tomcat        // tomcat 설치 디렉토리

workers.java_home=/usr/java/jdk1.7.0_40       // java  설치 디렉토리

worker.list=ajp13

worker.ajp13.port=8009

worker.ajp13.host=localhost

worker.ajp13.type=ajp13 



5. 사이트 설정 (virtualhost)

아파치 설정파일에 사이트를 추가합니다.

# vi /usr/local/apache/conf/extra/httpd-vhosts.conf

<VirtualHost *:80>

    DocumentRoot "/home/sysdocu/public_html"

    ServerName sysdocu.com

    ServerAlias www.sysdocu.com

    JkMount /*.jsp ajp13                 // 각 virtualhost 마다 추가

</VirtualHost> 


톰캣 설정 파일에 사이트를 추가합니다.

# vi /usr/local/tomcat/conf/server.xml

<Host name="sysdocu.com" appBase="/home/sysdocu/public_html" unpackWARs="true" autoDeploy="true">

    <Context path="" docBase="/home/sysdocu/public_html" crossContext="true" debug="0" reloadable="true"/>

    <Alias>www.sysdocu.com</Alias>

</Host>


아파치와 톰캣을 재시작하여 적용하도록 합니다.

jsp 가 잘 불러와지는지 확인을 위해 소스 기본 디렉토리에 index.jsp 라는 샘플 파일을 만들어 넣습니다.

 

# vi /home/sysdocu/public_html/index.jsp

<html>

<body>

<%

String str = request.getParameter("name");

if(str == null)

{ str = "JSP"; }

%>

Hello, <%= str %>!!!

</body>

</html> 

 

저장한 뒤, 사이트 접속을 하여 정상 출력되는지 확인합니다.

 

접속 URL : http://sysdocu.com/index.jsp

 

정상일 경우 출력 내용 : Hello, JSP!!!

잘못된 경우 출력 내용 : Hello, !!!  또는 소스 내용 출력

반응형

댓글()

TraceWatch 설치 (웹 통계 프로그램)

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

TrackWatch는 방문객이 드나든 경로를 파악하기 좋은 설치형 웹 통계 도구이다. 가입형인 구글 아날리틱스(Google Analytics)보다는 분석이 빈약하지만, 지역과 유형별로 분류된 접속자 현황을 곧바로 볼 수 있다.

 

TraceWatch 0.3판 이상은 PHP 5 이상, MySQL 4.1 이상을 지원하는 서버에서 돌릴 수 있다. PHP와 MySQL 조건이 이에 미치지 못한 곳에는 옛판인0.234판을 쓸 수 있다. 아래 설치 방법은 0.352판을 기준으로 한다.

 

[설치 방법]

1. TraceWatch 배포 파일을 받는다. TraceWatch만 있는 파일과 IP-to-Country 확장기능이 함께 든 파일이 있다. TraceWatch만 깔았다가 IP-to-Country 관련 파일을 더 설치하려면 좀 번거로우니, 접속 지역을 파악하고 싶다면 IP-to-Country Database가 함께 든 파일을 받는 쪽이 좋다.

 

2. 받은 파일을 압축을 풀어서 서버에 올린다. 여기에서는 웹 경로 뿌리의 /twatch에 올렸다고 가정한다.

 

3. /twatch/base/profile/default/settings.php을 열어서 다음 내용을 끼워넣는다.

 

$settings[ 'db_server' ] = '호스트 이름';  // localhost 또는 127.0.0.1 따위

$settings[ 'db_database' ] = 'DB 이름';

$settings[ 'db_username' ] = 'DB 사용자 이름';

$settings[ 'db_password' ] = 'DB 암호';

 

$settings[ 'root_username' ] = '사용자 이름';

$settings[ 'root_password' ] = '암호'; 

 

호스트 이름, DB 이름, 사용자 이름, DB 암호를 웹 계정의 MySQL DB에 맞는 값으로 바꾸어 넣는다. 아래쪽의 '사용자 이름'과 '암호'는 관리 화면에 들어갈 때 쓰인다.

웹 브라우저로 http://{설치 경로}/twatch/admin/install.php를 연다. settings.php에 넣었던 이름과 암호를 넣어 관리 화면으로 들어간다.

설치할 요소들과 시간대를 확인하고 Install TraceWatch를 딸깍한다. 문제 없이 설치되고 나면 마지막에 "TraceWatch installed successfully"라는 말이 나온다. "Some Error Occurred"라고 나오면 문제가 있는 것이므로, 앞서 고쳤던 settings.php에서 $setting[ 'unauthorized_muted_errors' ]의 값을 false로 바꿔서 오류 내용을 확인한다.

한글을 지원하는 언어 파일을 설치한다. 아르님의 한글 지원 언어 파일은 아르님의 블로그나 TraceWatch Language Pack에서 받을 수 있다. /twatch/Korean.php를 서버의 /twatch/locale에 올리고, /contry/Korean.php는 /twatch/country/locale에 올린다. (설정 부분은 아직 번역되지 않아 한글로 볼 수 없을 수 있다.)

분석할 웹 문서가 TraceWatch와 같은 서버에 있다면 다음 PHP 추적 코드를 집어 넣는다.

 

<?php

include_once $_SERVER[ 'DOCUMENT_ROOT' ].'/twatch/api/LogRequest.php';

twatchLogRequest();

?> 

 

위에서 $_SERVER[ 'DOCUMENT_ROOT' ]가 웹 계정에 따라 절대 경로를 제대로 가리키지 못할 때는 적절히 고쳐 써야 한다. PHP를 쓸 수 없거나 다른 서버에 있는 웹 문서에 붙일 추적 코드는 http://www.tracewatch.com/doc/code 에서 만들 수 있다. PHP를 쓸 수 없다면 자바스크립트를 쓸 수도 있다.

 

웹 문서에 추적 코드를 붙이고 나면 http://{설치 경로}/twatch에서 접속 정보와 통계를 볼 수 있다. 경로 분석(Path Analysis)은 통계를 잡기 시작하고 두세 날은 기다려야 볼 수 있다.

 

먼거리 PHP(remote PHP)나 자바스크립트로 추적 코드를 붙이지 않는다면, 그 기능을 꺼서 혹시라도 날아올지 모를 스팸을 막을 수 있다. 기능을 끄려면 /twatch/profiles/default/settings.php에서 다음 두 값을 false로 바꾼다.

 

$settings[ 'allow_js_logging' ] = false;

$settings[ 'allow_remote_logging' ] = false; 

 

[출처] 글걸이 (http://pat.im/829)

반응형

댓글()

[TOMCAT - ERRER] OutOfMemoryError: PermGen space

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

톰캣 구동중 프로세스가 자동으로 종료되며, 로그파일에 아래와 같이 남아있다면 몇가지 설정을 거쳐

정상 작동 되도록 조치합니다.

 

에러 로그 : OutOfMemoryError: PermGen space

 

처리방법

# vi /usr/local/tomcat/bin/catalina.sh

Heap 사이즈를 추가합니다.

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m

-Xmx1024m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:PermSize=512m

-XX:MaxPermSize=512m -XX:+DisableExplicitGC"

 

# vi /usr/local/tomcat/conf/web.xml

메모리 누수 방지를 위해 <servlet> 항목에 아래 내용을 추가합니다.

        <init-param>

            <param-name>enablePooling</param-name>

            <param-value>false</param-value>

        </init-param> 


반응형

댓글()

아파치에서 사용하던 인증서(.crt)를 톰캣에서 사용하기

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

Apache + Tomcat 환경에서는 아파치용 인증서(.crt)를 셋팅하여 사용할 수 있지만

tomcat 단독으로 웹서버를 사용하는 경우에는 기존 인증서를 pkcs12 형식으로 변환 해주어야 합니다.

 

1. 변환

# cd /usr/local/tomcat/conf

openssl pkcs12 -export -in sysdocu.crt -inkey sysdocu.key -out sysdocu.p12 -name tomcat

Enter pass phrase for sysdocu.key: (key 파일 암호입력)

Enter Export Password: (key 파일 암호입력)

Verifying - Enter Export Password: (key 파일 암호입력)

 

2. 확인

# keytool -list -v -keystore sysdocu.p12 -storetype pkcs12

 

3. 톰캣설정

# vi /usr/local/tomcat/conf/server.xml

 

<Connector port="443" maxHttpHeaderSize="8192"

    maxThreads="150" enableLookups="false" acceptCount="100"

    connectionTimeout="20000" disableUploadTimeout="true"

    protocol="org.apache.coyote.http11.Http11NioProtocol"

    SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS"

    keystoreFile="/usr/local/tomcat/conf/sysdocu.p12"

    keystoreType="PKCS12" keystorePass="(key 파일 암호입력)"/>

 

이후 톰캣을 재시작 하면 적용이 됩니다.

 

4. 확인방법

브라우저에서 아래와 같이 입력하여 확인이 가능합니다.

https://www.sysdocu.com

반응형

댓글()

Tomcat SSL 설정하기 (key, csr 생성)

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

- sysdocu -

apache 나 IIS 에서 사용하던 인증서(.crt 등) 는 톰캣 설정파일(server.xml)에 셋팅하여 사용이 불가능합니다.

인증서 발급기관에 신청할때 웹서버의 종류를 물어보는것으로 보아 웹서버 마다 인증서를 해석하는 방법이

다른것 같습니다.

톰캣을 단독으로 사용하는 웹서버의 경우에만 아래와 같이 진행합니다.

-------------------

 

1. 키파일 생성

keytool -genkey -keyalg RSA -alias hanbiro -keysize 2048 -keystore hanbiro.key

※ 참고사항(위의 빨간색 부분과 매칭되게
hanbiro는 키의 alias 이름으로 임의로 작성합니다.
hanbiro.key는 keystore이름으로 임의로 만듭니다

Enter keystore password: (비밀번호를 입력하세요.)

What is your first and last name?
[Unknown]: www.hanbiro.com (인증서 사용을 원하는 도메인)
What is the name of your organizational unit?
[Unknown]: LINUX (부서명)
What is the name of your organization?
[Unknown]: HANBIRO (업체명)
What is the name of your City or Locality?
[Unknown]: SEOCHO (지역명)
What is the name of your State or Province?
[Unknown]: SEOUL(시/도)
What is the two-letter country code for this unit?
[Unknown]: KR
Is CN=www.hanbiro.com, OU=LINUX, O=HANBIRO, L=SEOCHO, ST=SEOUL, C=KR correct?
[no]: y

Enter key password for <hanbiro>
(RETURN if same as keystore password): (엔터를 입력) 

키파일이 제대로 생성되었는지 확인해 봅니다. 
keytool -list -keystore hanbiro.key 


2. CSR 생성 

keytool -certreq -alias hanbiro -keyalg RSA -file hanbiro.csr -keystore hanbiro.key 

Enter keystore password: (키파일 생성시에 입력하였던 패스워드를 입력합니다.) 


3. 한비로(www.comodossl.co.kr) 에서 인증서 신청하실 때 위에서 생성하신 CSR 내용을 복사해서 붙여 넣은후 나머지 설치 절차를 거칩니다. 
생성된 CSR 을 출력하면 아래와 같은 base64 형식의 문서를 볼 수 있습니다. 

[root@ns root]# cat hanbiro.csr
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBsDCCARkCAQAwcDELMAkGA1UEBhMCS1IxDjAMBgNVBAgTBVN
lb3VsMQ8wDQYDVQQHEwZTZW9j
aG8xEDAOBgNVBAoTB0hhbmJpcm8xDjAMBgNVBAsTBUxpbnV4MR4w
HAYDVQQDExV3d3cucHJvZGln
AAGgADANBgkqhkiG9w0BAQQFAAOBgQBhV3jIaT2wEOB1/AIOedu+4
gECrr+6UIYhwPtSmIeoWXg5
76+UHe5I1M2M/ew5j6d8pq4IBXaTesSrmwZuuuA2Stx4uXjb/Akjr8UIDX
isnycJGmk5dQDCCT3G
8IBd8gwgvQOiAhnfGSjIbStsPOiVCgB60uSz9Jc8s9rPIxh69w==
-----END NEW CERTIFICATE REQUEST-----


-----BEGIN … 부터 마지막 줄 -----END … 까지 복사하여 지정된 SSL 접수페이지에 복사하여 붙여 넣은 뒤 입력정보와 함께 전송하면 접수가 완료됩니다. 


4. 인증서 설치

keytool -import -trustcacerts -alias COMODOSSL -file
COMODOSSLCA.crt -keystore hanbiro.key

keytool -import -trustcacerts -alias INTER -file
AddTrustExternalCARoot -keystore hanbiro.key

keytool -import -trustcacerts -alias hanbiro -file
www_hanbiro_crt -keystore hanbiro.key


##주의##
Free SSL 및 PostiveSSL 의 경우, PostiveSSLCA.crt 파일을 추가 하지 않았을 경우,
아래와 같은 메세지가 표시 되며 저장 되지 않으니 반드시 아래 작업을 진행하여 주시기 바랍니다.

에러내용
keytool error: java.lang.Exception: Failed to establish chain from reply 

추가내용 
keytool -import -trustcacerts -alias POSITIVESSL -file PositiveSSLCA.crt -keystore hanbiro.key 

5. 서버설정

Server.xml을 설정합니다. 

Tomcat 버젼 6.X 의 경우.. 
<!--Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector port="443"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true" SSLEnabled="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="키스토어파일경로/hanbiro.key"
keystorePass="(hanbiro.key 패스워드)" /> 

Tomcat 버젼 5.X 의 경우.. 
<!--Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector port="443"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="키스토어파일경로/hanbiro.key"
keystorePass="(hanbiro.key 패스워드)" /> 

Tomcat 버전 4.X 의 경우. 
<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> 
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="443" minProcessors="5" maxProcessors="75"
enableLookups="true"
acceptCount="100" debug="0" scheme="https" secure="true"
useURIValidationHack="false" disableUploadTimeout="true"> 
<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
clientAuth="false" protocol="TLS"
keystoreFile="키스토어파일경로/hanbiro.key"
keystorePass="(hanbiro.key 패스워드)" /> 


6. 톰캣을 재시작 합니다.

shutdown.sh
startup.sh

 

[출처] http://www.comodossl.co.kr / http://www.instantssl.com

반응형

댓글()