##

## httpd.conf -- Apache HTTP server configuration file

##

httpd.conf 파일은 크게 세부분으로 나누어져 있다.

    Section 1: Global Environment  : 아파치 전체적인 영향이 미치는 설정
    Section 2: 'Main' server configuration : 주 서버에 대한 설정
    Section 3: Virtual Hosts : 가상 호스트에 대한 설정

     ### Section 1: Global Environment

전제환경설정 파트로 Section 1에서 설정하는 것들은 아파치 웹서버에

전반적인 영향을 미친다.

ServerType standalone

서버의 구동방법으로는 standalone과 inetd방식이 있는데,  standalone
방식은 하나의 웹데몬(아파치서버)이 클라이언트의 접속을 모두 처리하는
방식으로 응답속도가 빠른 방법으로 주로 이방식을 사용한다. inetd 방식은
inetd라는 시스템의 /etc디렉토리 끝에 존재하는 inetd라는 슈퍼데몬이
클라이언트의 접속요구가 있을 때마다 웹서버를 구동하는 방식이다.
일반적으로 응답속도가 빠르고 효율적인 standalone으로 설정하여 사용한다.

ServerRoot "/usr/apache"

아파치서버의 홈디렉토리를 지정하며 절대경로로 지정한다. 이후로 나오는
대부분의 패스들은 이 경로에 대한 상대경로로 지정이 된다. 예를 들어
환경설정파일, 에러로그파일등의 상대경로의 기준이 되는 위치이다.

LockFile logs/accept.lock

아파치 컴파일시 USE_FCNTL_SERIALIZED_ACCEPT나

USE_FLOCK_SERIALIZED_ACCEPT으로 컴파일 했을 때 사용되는
LockFile의 경로지정시에 사용된다. 가급적 기본값으로 사용한다.

    LockFile /usr/apache/logs/httpd.lock

PidFile logs/httpd.pid

PidFile 설정은 ServerType을 Standalone으로 설정했을때만 유효한
것으로 아파치 서버의 프로세스가 생성되어 있을 때 그 프로세서ID(PID)를
기록하는 파일을 지정한다.  당연히 아파치서버가 재시작되거나 과부하로
인해 PID가 바뀌게 될 경우에는 이 파일의 PID값도 바뀌게 된다.  즉
다시말해서 여기서 지정된 파일(httpd.pid)에 실행되고 있는 아파치서버의
프로세스번호(PID)값이 기록된다고 하면 정답이다. ServerRoot를 기준으로한
상대경로로 지정된다.  절대경로로 지정하려면 "/"로 시작하는 절대경로를
적어주면 된다.

    PidFile /usr/apache/logs/httpd.pid

ScordBoardFile /usr/apache/logs/httpd.scoreboard

내부 서버 프로세서 정보를 저장하는데 사용된다. 모든 아키텍쳐가 이것을 필요로 하진 않는다.

ResourceConfig conf/srm.conf
AccessConfig conf/access.conf

아파치 서버의 환경설정파일은 3개이다. au httpd.conf, srm.conf, access.conf
가 그것이다. 그러나 하나의 설정파일로 하는 것이 효율적이기 때문에
지금은 httpd.conf파일안에 3개의 파트(Section)로 나누어서 하나의
파일안에서 설정을 하고 있다. srm.conf와 access.conf파일의 내용은 현재
비어있는 상태이지만, 필요하다면 이 파일 내에도 설정을 할 수 있다.
아파치 서버가 실행이 될 때는 httpd.conf, srm.conf, access.conf 순으로
언제나 이 3개의 파일을 모두 읽고 난뒤에 실행이 되기 때문이다. 만약 이
두 개의 파일을 서버가 무시하도록 하려면 다음과 같이 하거나 "#"으로 붙여
두면 주석처리되어 무시된다.

    #ResourceConfig /usr/apache/conf/srm.conf
    #AccessConfig /usr/apache/conf/access.conf

   
Timeout 300

클라이언트의 요청에 의해 서버와 연결이 되었을 때 클라이언트와
서버간에 아무런 메시지가 발생하지 않았을 때 오류로 처리될 시간을
초단위로 설정한다. 초기값은 1200이며 보통은 300초로 지정을 한다.
네트웍의 속도가 나쁠수록 수치값은 높게 설정하는 것이 좋다.

KeepAlive On

접속한 채로 특별한 요청없이 지속적인 연결을 허용할 것인지를 설정한다.
허용하지 않으려면 off

MaxKeepAliveRequests 100

클라이언트가 접속된 시간동안 아파치서버에 요청할 수 있는 최대의
개수를 지정한다. 0을 지정하면 제한없음을 의미하며, 서버의 성능향상을
위하여 가능한 높은 값이 좋다.
 
KeepAliveTimeout 10

아파치 서버는 같은 접속상태의 클라이언트에서 여기서 지정한 초만큼의
요청이 없었을 때 접속을 끊게 된다.

MinSpareServers 5
MaxSpareServers 10

아파치 웹서버는 성능향상과 빠른 응답속도를 위해 유휴서버(현재 서비스대기 중인

프로세스)를 만들게 되는데 이 유휴서버의 개수는 시스템의 상황에 따라 달라지게 된다.

유휴서버가 MinSpareServers의 개수(5) 보다 적게되면 추가로 생성을 하게 되며 MaxSpareServers의 개수(10)보다 많게 되면 죽이게 된다.

즉, 유휴서버의 개수를 적절히 조절하기 위한 것이라 생각하면 된다.

StartServers 5  

아파치 웹데몬이 구동될 때 자식프로세스를 몇 개로 할 것인가를 지정한다.

시작할 때 동시에 띄우게 될 웹데몬의 개수이다. 그러나 웹데몬이 구동되고 난 뒤엔 시스템의 상황(부하율등)에 따라 대부분 합리적인 개수만큼 동적으로 생성되었다가 죽기도 하므로 큰 의미를 가지는 것은 아니다.

MaxClients 150

아파치웹서버에 접근할 수 있는 클라이언트의 최대갯수는 이 상한값으로
제한한다. 여기서 지정한 개수이상의 클라이언트의 요청이 생긴다면
아파치는 응답하지 않고 이 요청을 무시한다.  이를 제한하는 이유는
시스템의 자원을 아파치 웹서버가 무한정 차지하는 것을 방지하기 위한
것이다.

MaxRequestsPerChild 30

아파치 웹서버의 자식프로세스들이 클라이언트의 요청 개수를 지정한다.
만약 자식프로세스가 이 값만큼의 클라이언트요청을 받았다면 이 자식프로세스는 자동으로 죽게된다. 이 값이 0으로 설정이 된다면 자식프로세스가 자동으로 죽는일은 없을 것이다. 그러나 0아닌 다른 값으로 설정함으로서 프로세스의 수를 적절히 조절하여 시스템의 부하조절과 자원낭비를 어느정도 방지 할 수 있다.

Listen 3000
Listen 12.34.56.78:80

사용자 Request를 대기하는 port 시스템의 기본값이외에 다른 IP Address와 포트에 대해서도 연결할 수 있도록 해 준다. 환경설정파일(httpd.conf) 맨뒤에 나오는 가상호스트(Virtual
Host)부분에서 설정되는 가상호스트를 설정하기 위해 필요하다.

BindAddress *

서버가 응답할 수 있는 IP Address를 설정하는 것이다. 하나의 시스템에
있는 아파치웹서버 하나로 여러 웹서버처럼 관리하는 웹호스팅서비스등에서
많이 이용하는 것으로 여러 IP Address를 인식할 수 있게 한다. "*"으로
설정이 되었다면 모든  IP Address에 대해 응답할 수 있으며, IP Address를
지정한다면 지정한 IP Address에 대해서만 응답할 수 있게 된다.  여러개의
IP Address를 ISP로부터 할당받아서 웹호스팅서비스를 하고자 한다면
이부분에서 지정해 주면된다. 이 설정파일의 맨 뒷부분에 나오는
<VirtualHost>~</VirtualHost>부분의 IP bind 가상호스트부분에서 아파치
웹서버가 응답할 수 있도록 하려면 여기서 IP Address를 지정해 줘야 한다.

ExtendedStatus On

server-status로 아파치웹서버의 상태를 상태를 모니터링 할 때
"자세한상태정보"기능을 제공할 것인지(On) 아닌지(Off)를 설정하는 것이다.

     ### Section 2: 'Main' server configuration

Section 2에서 설정하는 항목들은 아파치의 주된서버가 사용할 값들을
지정한다. <VirtualHost>에 정의된 가상호스트들에서 지정하지 않는 것은
여기서 지정된 값이 기본값으로 적용된다. 또한 여기서 지정하는 값을 각
<VirtualHost>내에도 지정할 수 있으며 이경우엔 각<VirtualHost>내에서
지정한 값이 우선적용된다.

Port 80

아파치웹서버의 기본포트를 지정한다. 특별하게 사용하는 것이 아니라면
80번으로 해둬야 한다. 사용가능한 포트는 0 ~ 65535이며 1024이하의
포트번호는 시스템에서 특별하게 예약되어 있으므로 80번 이외의 다른
포트를 사용하려면 1024이상의 포트번호를 지정해서 사용해야 할 것이다.
특별한 지정이 없다면 <VirtualHost>에 정의된 각각의 가상호스트들의
기본포트가 된다. 만약 <VirtualHost> 내에서 Port가 지정이 된다면 그
포트번호가 우선한다.

(특별히 PORT를 따로 지정해 줄 필요가 있을 때는 따로 지정해 주며,
이때는 웹서버로 접근할 때 반드시 따로지정한 PORT번호로 접근해야 한다.
예를들어 Port 1234로 지정했다면, 접근시 : http://www.domain.co.kr:1234
로 접속해야한다. 단, 80번은 default이므로 Port번호를 입력하지 않아도
도메인만으로 그냥 접근할 수 있다. 예: http://www.domain.co.kr )

SSL Support

SSL을 제공하고자 할때 HTTP port와 HTTPS port를 listen해야 한다.

    <IfDefine SSL>

    Listen 80

    Listen 443

    Listen 8888

    </IfDefine>

User nobody
Group nobody

아파치 웹데몬이 요청을 받았을 때 여기서 지정한 user와 group으로
응답을 하게된다. 이 설정은 ServerType이 Standalone방식이며, 아파치의
실행이 root권한으로 실행이 되었을 때 유효한 것이다. 많은
웹서버관리자들이 nobody로 설정을 해 두고 있으며, 만약 시스템에 nobody
user가 없다면 새로생성(useradd)을 해야 할 것이다. 단, root로 설정하는
것은 절대로 있어서는 안되며 nobody이외의 다른 시스템사용자 id로 지정을
한다면 정말 신중히 모든면(시스템 보안 및 자원사용등)에서 깊게 고려를
해봐야 한다.

ServerAdmin webmaster@www.domain.co.kr

여기서 지정하는 email address는 웹문서 로딩에러등의 문제에서
클라이언트측으로 보내질 메일주소값이다. 대부분
웹서버관리자의 email address로 설정을 한다.

ServerName new.host.name

클라이언트에게 보여주는 호스트이름을 지정한다. www를 쓰지않는
호스트에서 www를 쓰는 것처럼 보이게 할 수 있다. 예를 들어
bbs.manualand.co.kr을 www.manualand.co.kr로 지정해서 쓸 수 있다.
이곳에 IP Address를 적게 되면 클라이언트에는 Ip Address를 보여준다.

DocumentRoot "/usr/local/apache/htdocs"

아파치 웹서버의 웹문서가 있는 경로를 지정한다. 예를 들어
"http://www.manualand.co.kr/index.html"의 초기 문서라면 이 초기문서의
절대 경로는 여기서 지정된 "/usr/local/apache/htdocs/index.html"이 된다.
경로의 맨 마지막에 "/"를 추가해서는 안된다. Alias를 사용하여 다른 위치를
지정할 수도 있다.

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>                      

<Directory>에서 지정되는 값에 대한 옵션은 다음과 같은 의미를 가지고
있다.
        None : 일단 모든허용을 하지 않는다.
        All : 모든허용을 한다.
        Indexes :
        Includes :
        FollowSymlinks :
        ExeCGI :
        MultiViews :

UserDir public_html

<IfModule mod_userdir.c>

    UserDir public_html

</IfModule>

하나의 아파치 웹서버에서 여러 사용자의 홈페이지를 별도로 만들어
관리할 때 필요한 개별 가입자의 홈페이지 디렉토리이름이다. 예를 들어
sspark이란 계정가입자의홈페이지는 "http://manualand.co.kr/~sspark"라는
홈페이지를 가지고 있을 때 sspark의 계정에서 "public_html"이란
디렉토리가 홈디렉토리가 되어 이 디렉토리에 있는 초기문서 index.html을
불러서 보여주게 된다.

<Directory /home/*/public_html>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes SymLinksIfOwnerMatch
IncludesNoExec
    <Limit GET POST OPTIONS PROPFIND>
        Order allow,deny
        Allow from all
    </Limit>
    <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY
MOVE LOCK UNLOCK>
        Order deny,allow
        Deny from all
    </Limit>
</Directory>

계정사용자의 홈페이지(public_html)의 접근에 대한 옵션을 지정한 것이다.

DirectoryIndex index.html

디렉토리만을 지정했을 경우에 그 디렉토리에서 찾게될 문서의 순서를
지정해 준다. 즉, 디렉토리 이름만을 지정하더라도 여기서 지정한
index.html을 찾아서 웹브라우즈에 보여준다. 여러개의 파일을 지정할 수
있으며, 이런 경우에는 순서대로 찾아서 보여준다. 예를 들어
"DirectoryIndex index.html index.htm"로 지정했다면 먼저 "index.html"을
찾아서 있다면 이 파일을 로딩하고, "index.html"이 없다면 "index.htm"을
찾아서 로딩해 준다.

AccessFileName .htaccess

디렉토리별로 접근제어할 정보(ID, Password)를 담고 있는 파일을
지정한다. 디렉토리별로 인증을 거쳐서 접근할 수 있는 설정을 하기위한
것이다. 예를 든다면 어떤 홈페이지의 전부나 혹은 일부에로 접근하려고 할
때 ID, Password를 묻는 창이 뜨면서 맞게 입력한 경우에만 접근허용하는
것이다.  보안상의 이유로 이 파일의 이름을 다른 이름으로 바꾸로 싶다면
".htaccess"대신에 다름이름을 적어주면 된다.

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

바로위에서 설정한 파일(".htaccess")의 내용을 볼 수 없게 할 때 사용하는
옵션이다. 보안상의 이유로 이 옵션은 설정해 두는 것이 좋다. 만약 이
옵션을 주석처리해 둔다면 ".htaccess"파일에 대한 보안은 누구도 장담할 수
없을 것이다.

CacheNegotiatedDocs

디폴드로 아파치는 content와 연관된 각각의 document에 "Pragma: no-cache"를 보낸다.

이것은 proxy 서버가 document에 cache를 사용하지 않을것인지를 묻게 된다.

이 라인을 주석처리 하면 documents에 cache를 허용할수 있게 된다.

#CacheNegotiatedDocs

UseCanonicalName On

On으로 설정하면, self-referencing URL을 만들때마다 "canonical" name 형식에 따른 hostname과 port를 사용할것이다.

Off로 설정하면 아파치는 가능하면 client가 제공한 hostname과 port를 사용할것이다.

이것은 또한 CGI 스크립트의 SERVER_NAME과 SERVER_PORT에 영향을 준다.

TypesConfig conf/mime.types

웹서버의 mime type을 지정한 파일을 지정한다. mime.types파일은 서버에
의해 리턴될 수 있는 파일명과 mime형식을 기술해 놓은 파일이다.

  <IfModule mod_mime.c>

       TyperConfig /usr/apache/conf/mime.types

   </IfModule>

DefaultType text/plain

mime.types 파일에 정의 되어있지 않은 파일형식에 대한 요청을 받았을 때
알 수 없는 문서타입에 대하여 사용할 기본적인 mime 타입을 정해둔다.

<IfModule mod_mime_magic.c>

    MIMEMagicFile /usr/apache/conf/magic

</IfModule>

HostnameLookups Off

웹서버의 로그(access_log)를 지정하는 Format에서 "DNS Lookup"으로
지정하였을 때, domain으로 남길 것인가, IP Address로 남길 것인가를
지정한다. Default로 Off는 IP Address로 남기는 것이며, Domain으로 변경할
필요가 없으므로 on으로 설정한 것보다는 속도가 조금빠르다.on으로 하게
되면 IP address를 IP Domain으로 변환해야 하므로 속도가 조금 느릴 수
있다.

ErrorLog /usr/apache/logs/error_log

아파치 웹서버의 에러로그 기록파일을 지정한다.  참고할 사항은 맨마지막에 설정하는 <VirtualHost>부분에서 각서버에 대한 에러파일을 지정해 두지 않으면 그에 대한 에러로그도 여기에 기록되며, 지정해 두게 되면 그에 해당하는 로그는 이 파일에 기록되지 않는다.

LogLevel warn

바로위에서 설정한 에러로그 파일에 얼마나 자세하게 적을 것인지를
결정한다. 다음에 해당하는 순서대로 중요도가 정해진다.

" debug → info → notice → warn → error → crit → alert → emerg "

아래에서 사용할 CustomLog에서 사용자지정 환경변수 지정을 사용할수 있다.

해당 항목에 대해서는 log파일에 추가되지 않음.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combind
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

바로 아래에서 사용할 CustomLog에서 사용할 몇가지 로그형식의 별명을 정한 곳이다.
웹서버의 관리자나 서버관리자는 이 부분을 특히 유심히 봐둬야 한다.
웹서버의 로그를 어떤 식으로 남길 것인가를 결정하는 Format을 지정하는 곳이다.

원하는 정보를 지정해서 볼 수 있으므로, 관리자에게 필요한 Format으로 설정해야 하며,

또한 접속통계를 내기에 적당한 Format으로 설정해 둬야 한다.

CustomLog /usr/apache/logs/access_log common env=!dontlog

위에서 정한 로그형식(여기선 common)대로 로그를 남기게 된다.
맨마지막에서 지정하는 <VirtualHost>부분에서도 아파치 1.3.9버전 부터는
CustomLog를 가상호스트별로 지정할수 있도록 CustomLog를 제공한다.
<VirtualHost>에서 CustomLog를 지정하지 않으면 여기서 지정한 형식대로
로그를 남기게 되며 <VirtualHost>부분에서 CustomLog를 지정했을
경우에는 여기서 지정한 로그형식은 무시된다.

#CustomLog  /usr/apache/logs/referer_log referer
#CustomLog  /usr/apache/logs/agent_log agent
#CustomLog  /usr/apache/logs/access_log combined

위에서 지정한 4가지의 로그형식(combind, common, referer, agent)중에서
원하는 부분의 #(주석행)을 제거하면 지정된다.

ServerSignature On

Optionally하게 서버가 생성하는 문서(error documents, FTP directory listings, mod_status and mod_info output etc., but not CGI generated documents)에 서버 버전과 가상호스트 이름을

포함하는 라인을 추가한다. 
"EMail"로 설정하면 mailto에 의해 SeverAdmin에 링크된다.

ON | OFF | EMail

EBCDIC configuration:

Fujitsu-Siemens' BS2000/osd, IMB's OS/390, IMB's TPF 과 같은 메인프레임에서만

EBCDIC 코드셋을 사용한다.

아래의 디폴트 설정은 bianary 파일이 ASCII 머신에  저장될때 text 파일이 EBCDIC에 저장된다구 가정한다. 따라서 일반적인 POSIX 툴이나 grep, sort를 이용하여 조작할수 있다.

    EBCDICConver tByType On=InOut text/message/multipart/

    EBCDICConver tByType On=In      application/x-www-form/urlencoded

    EBCDICConver tByType On=Inout  application/postscript model/vrml

    EBCDICConver tByType Off=InOut

ASCII HTML 문서와 EBCDIC HTML 문서를 동시에 사용하고자 한다면, ASCII 문서에 전환을 위한 파일 확장자를 사용할수 있다.

    AddType            text/html  .ahtml

    EBCDICConvert Off=InOut  .ahtml

Alias /icons/ "/usr/local/apache/icons/"

필요한 만큼의 디렉토리 별칭을 만들어 쓸 수 있다. 사용하는 형식은 다음과 같다.
Alias fakename(가상이름) realname(진짜이름)

fakename이 /로 끝나면 서버는 그것이 표현된 URL을 요구할것이다.

fakename이 /로 끝나면 realname도 /로 끝나야 한다.

fakename이 /를 생략하면 realname로 /를 생략해야한다.

    Alias /icons/ "/usr/local/apache/icons/"

    <Directory "/usr/local/apache/icons">
          Options Indexes MultiViews
          AllowOverride None
          Order allow,deny
          Allow from all
    </Directory>

ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"

ScriptAlias는 서버스크립트를 포함한다. ScriptAlias는 실제디렉토리 안에
들어있는 문서를 서버에 의해 응용프로그램으로 취급되어 실행되는 것을
제외하고는 근본적으로 Aliases와 같다.

Redirect old-URi new-URL

client에게 서버의namespace에 문서가 더이상 존재하지 않을때 clinet에게 재위치된 문서가

어디에 있는지 알려준다.

    Format: Redirect old-URI new-URL

IndexOptions FancyIndexing

IndexOPtions는 디렉토리목록을 표시할 때 사용할 옵션을 지정한다.
Standard는 표준적인 디렉토리를 나타내며, FancyIndexing은 좀더 예쁜
디렉토리목록을 표시해 준다.

AddIcon*

아래에서 지정하는 AddIcon으로 시작하는 설정은 바로위에서 설정한
디렉토리인덱싱 옵션을 FancyIndexing으로 한 경우에 해당하며 디렉토리
목록을 표시할 때 각 파일 확장자에 따라서 어떤 아이콘을 선택하여 보여줄
것인지를 지정한다.

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

DefaultIcon /icons/unknown.gif

여기서 지정한 확장가가 아닌 경우에 여기서 지정한 기본아이콘으로
보여준다.

AddDescription "GZIP compressed document" .gz
AddDescription "tar archive" .tar
AddDescription "GZIP compressed tar archive" .tgz

AddDescription은 서버가 생성한 인덱스의 파일 뒤에 간단한 설명을
표시할 때 사용한다. 이 설정은 IndexOptions가 FancyIndexing으로
설정되었을때만 표시되며, 설정형식은 다음과 같다.
형식 : AddDescription "표시할 설명" 파일확장자

ReadmeName README

ReadmeName은 디렉토리목록표시 뒤에 붙여서 보여줄 README파일의
이름을 지정한다.(일종의 꼬릿말)

HeaderName HEADER

HeaderName은 디렉토리목록표시 앞에 붙여질 파일의 이름을 지정한다.
(일종의 머릿말)

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

디렉토리목록을 인덱싱할 때 제외할 파일명을 지정한다. 즉 디렉토리
목록에 포함하지 않을 파일을 지정한다. 쉘스타일의 와일드카드(*, ?)가
허용된다.

AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

AddEncoding은 특정브라우즈(Mosaic/X 2.1+)에서 받고있는 중에 정보에
대한 압축해제를 할 수 있도록한다. 단 모든 웹브라우즈에서 이 기능을
제공하는 것은 아니다.

AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it

AddLanguage는 문서의 언어를 지정하게 한다.

LanguagePriority en fr de

언어의 우선순위를 내림차순으로 지정한다.

AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
AddType application/x-tar .tgz

AddType은 mime.types의 실제 편집없이도 mime을 설정할 수 있다.

또한 특정 type에 특정 files을 만들게도 할수 있다.

AddHandler cgi-script .cgi

AddHandler는 파일확장자를 처리기(Handler)에 매핑(연결)시켜주게 된다.

서버 측면의 include나 CGI outside ScriptAliased directories를 사용하려면

이 라인을 주석처리 하면 된다.

AddType text/html .shtml
AddHandler server-parsed  .shtml

server-parsed HTML 파일을 사용하려고 할때

#AddHandle send-as-is asis

Apache의 send-asis HTTP 파일특성의 사용을 위해서는 이 라인을 주석처리할것.

#AddHandle imap-file map

server-parsed imagemap 파일을 사용하려고 할때

SSI(Server Side Include)문서를 인식하게 하기위한 설정이다. SSI코드가
들어가 있는 문서는 확장자가 *.shtml이다. 시스템의 날짜와 카운터등
CGI프로그램을 하지 않아도 HTML문서에서 단 몇줄로 CGI의 효과를 낼 수
있는 SSI기능을 인식하게끔 하는 설정이다.

#Format: Action media/type /cgi-script/location
#Format: Action handler-name /cgi-script/location

Action은 매칭되는 파일이 호출될때마다 스크립트를 실행시킬 수 있도록
미디어 타입을 정의한다.

MetaDir .web

MetaDir은 아파치가 찾을 메타정보파일들의 디렉토리이름을 지정한다. 이
파일들은 문서를 전송할 때 포함되는 HTTP 헤더정보가 포함되어 있다.

MetaSuffix .meta

MetaSuffix는 메타정보를 포함하고 있는 접미어의 이름을 지정한다.

에러발생시 응답을 정의할 수 있는 방법을 3가지 나타내고 있다.

    1) 일반적인 텍스트

ErrorDocument 500 "The server made a boo boo.

    2) 지역적인 방향전환

ErrorDocument 404 /missing.html
ErrorDocument 404 /cgi-bin/missing_handler.pl

    3) 외부 방향전환

ErrorDocument 402
http://some.other_server.com/subscription_info.html

  다음의 BrowserMatch는 keepalives기능을 쓰지못하게 하며 HTTP
헤드방식을 설정한다.

BrowserMatch "Mozilla/2" nokeepalive

  이 설정은 Netscape 2.x 또는 이를 따르는 브라우즈에 대하여 KeepAlive
기능을 쓰지 못하게한다.

BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0
force-response-1.0

  이 설정은 잘못구현된 HTTP/1.1과 301또는 302반응에 대하여
KeepAlive를 적절히 제공하지 못하는 마이크로소프트 인터넷익스플로러
4.0b2d에 관한 것이다.

BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

  위의 3가지 설정은 기본적인 1.1반응도 처리하지 못하며 HTTP/1.0 스팩을
제한하고 있는 브라우즈에 대하여 HTTP/1.1반응을 하지 못하게 한 것이다.

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from www.manualand.co.kr
</Location>

  서버의 상태를 점검할 수 있게하는 설정이다. 이는
"http://www.manualand.co.kr/server-status"와 같은 형식으로 서버의 상태를
점검할 수 있다. "6장. 아파치서버 모니터링"편에서 자세히 설명되어 있다.
여기서 지정한 "SetHandler server-status"의 설정으로 인해 서버
모니터링을 할 수 있는 것이다.

<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from www.manualand.co.kr
</Location>

  이설정을 위해서는 mod_info.c가 적재되어야 하며, 이는
"http://www.manualand.co.kr/server-info"와 같은 방식으로 서버의 정보를
볼 수 있다. 위에서 설정한 server-status와 함께 실행중인 웹서버의
상태점검을 위한 것이다.

<Location /cgi-bin/phf*>
    Deny from all
    ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
</Location>

  아파치 1.1이전 버전의 오래된 버그에 대한 악용이 있을시에는 지정한곳
(http://phf.apache.org/phf_abuse_log.cgi) 으로 방향을 전환시킨다.

<IfModule mod_proxy.c>
ProxyRequests On

  아파치 웹서버를 Proxy서버로 사용할 때 on을 해줘야 한다. 즉   
프락시서버 지시자로서 프락시서버를 on 시킨다.

<Directory proxy:*>
    Order deny,allow
    Deny from all
    Allow from .your_domain.com
</Directory>

ProxyVia On

  HTTP/1.1 "Via:"헤드처리를 활성화시킬 것인지 비활성화 시킬것인지를
지정한다. Off, On, Full, Block중 하나가 올 수 있으며 Full은 서버버전을
포함하며, Block은 나가는 모든 것에 대해 Via:헤더를 제거한다.

CacheRoot "/usr/local/apache/proxy"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
NoCache a_domain.com another_domain.edu joes.garage_sale.com

  이 설정은 캐시기능을 활성화 하기 위한 것이다.

### Section 3: 가상호스트 설정

  여러분의 시스템에서 여러개의 도메인이나 호스트네임을 설정하여
관리하고자 한다면 <VirtualHost>부분을 설정해 줘야 한다. 가상호스트에
대한 정보는 http://www.apache.org/docs/vhosts/를 참조해 보면 좀더
자세한 정보를 얻을 수 있다.  '-S'옵션을 사용함으로써 가상호스트의 설정에
대한 점검을 할 수 있다.  name-based 가상호스트를 사용하길 원한다면
적어도 한 개이상의 IP Address를 정의할 필요가 있다. "4-2절의 내용"과
"10장.웹호스팅 서비스를 위한 가상호스트"편에서 자세히 설명되어 있다.

NameVirtualHost 12.34.56.78:80
NameVirtualHost 12.34.56.78

<VirtualHost www.manualand.co.kr>
    ServerAdmin webmaster@manualand.co.kr
    DocumentRoot /home/sspark/public_html
    ServerName www.manualand.co.kr
    ErrorLog /home/sspark/public_html/aw/error_log
    CustomLog /home/sspark/public_html/aw/access_log common
</VirtualHost>

        ServerAdmin은 해당서버의 관리자 전자우편이며,
        DocumemtRoot는 해당서버의 홈디렉토리이며,
        ServerName은 해당서버의 도메인이며,
        ErrorLog는 해당서버의 에러파일 위치이며
        CustomLog는 로그파일위치와 포맷을 지정한 것이다.

<VirtualHost _default_:*>
</VirtualHost>

  Default 가상호스트 설정으로 위에서 설정되지 않은 다른 모든 호스트에
대해서 응답을 하고자 할 경우설정해 준다.

FreeBSD설치 안내서 입니다.

pdf포맷이고 한글이며 저작권에 관해서는 파일내를 참고하세요...

Copy & Paste 가 제대로 안되서 그냥 pdf파일로 만듬

내가 FreeBSD를 설치를 하고 거기에 Oracle까지 설치를 하게 될줄은 몰랐음...

재미있긴했으나...

OS를 설치하는건 역시 노가다였음-_-

r1.2과 현재 버전의 차이점

ftp://ftp4.kr.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/

번호	설명
1	기본적인 부팅이다. 일반적으로 설치를 할때 선택한다.
2	ACPI 기능을 활성화 시켜서 부팅한다.
3	안전모드로 부팅한다.
4	싱글 모드로 부팅한다. 비상시에 사용한다.
5	verbose logging 모드로 부팅한다.
6	부트로더 프롬프트로 빠져나간다.
7	재부팅한다.

번호	설명
Standard	가장 기본적인 설치 방법이다.
Express	좀더 빠른 설치 방법이다. 전문가에게 권장
Custom	설치하고 싶은 것만 설치할 수 있는 방법이다. 역시 전문가에게 권장
Configure	설정을 추가하거나, 변경하고 싶을 때 선택한다.
Doc	설치 관련 문서를 볼 수 있다.
Keymap	키보트 타입을 설정한다.
Options	설치옵션을 보거나 설정할 수 있다.
Fixit	비상모드로 고칠때 선택한다.
Upgrade	소프트웨어를 업그레이드 할 때 선택한다.
Load Config	설치 설정 파일을 읽어 들인다.
Index	함수를 검색한다.

엠파스 블로그에서 펌~~

/etc/mail/sendmail.mc 에서 아래 부분을 수정한다.

# vi /etc/mail/sendmail.mc

127.0.0.1 부분을 찾아 삭제
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')
위 두줄앞에 있는 dnl 을 삭제

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
# /etc/rc.d/init.d/sendmail restart

설정이 완료된 순간부터 access.db 의 내용은 무시되며
서버 로그인 정보를 이용하여 메일 보내기가 가능해진다.

아웃룩 설정부분에서 아래부분을 체크한다.

'계정속성 -> 서버' 아래쪽에 있는 '보내는 메일 서버' 의 '인증필요' 부분을 체크.

한글 putty~~~

DMZ (DeMilitarized Zone)

외부에서 엑세스가능한 서버들의 네트웍을 할당해 놓은 곳

방화벽의 종류중에, Screened subnets 라는 종류에서
앞뒤로 방화벽을 설치해 놓고, 중간에 서버를 가져다 놓는데,

이 부분을 DMZ 라고 부른다.

더 자세한 것은 방화벽을 찾아보면 자세히 나와있습니다.

컴퓨터 네트웍에서, DMZ란 회사의 사설 네트웍과 외부의 공중 네트웍 사이에, 중립 지역으로서 삽입된 컴퓨터 호스트, 또는 소형 네트웍을 말한다. 이것은 외부의 사용자들이 회사의 중요 데이터를 가지고 있는 서버에 직접 접속하는 것을 방지한다 (이 용어는 1950년 초 한국전쟁 후 남북한 사이에 조성된 지리적 완충지역을 부르는 말로부터 유래되었다). DMZ를 두는 것은 선택 사항이지만, 방화벽 보다 더 안전한 방법이며, 게다가 프록시 서버로서의 역할도 효과적으로 수행한다.

소규모 회사를 위한 대표적인 DMZ 구성에서, 별도의 호스트 컴퓨터가 사설 네트웍 내의 사용자들로부터 웹사이트 또는 공중 네트웍 상의 다른 회사 컴퓨터의 접속에 관한 요청을 받는다. 그리고 나서 DMZ 호스트는 공중 네트웍에 관한 이러한 요청을 위해 세션을 개시한다. 그러나, DMZ 호스트는 사설 네트웍 내로 들어오는 세션은 개시할 수 없다. DMZ 호스트는 오직 요청된 패킷들을 내부로 전달하는 것만이 가능하다.

회사 외부의 공중네트웍의 사용자들은 오직 DMZ 호스트만을 액세스할 수 있다. DMZ 호스트에는 일반적으로 외부 세계에 서비스할 수 있도록 회사의 웹페이지를 가지고 있을 수 있지만, 그 외 회사의 어떠한 다른 데이터도 제공하지 않는다. 그러므로, 만약 외부의 사용자가 DMZ 호스트의 보안을 뚫고 침입한 경우, 웹페이지는 훼손될 수 있지만, 그 외 회사의 다른 어떠한 정보도 노출되지 않는다. 라우터 제작으로 유명한 시스코에서, DMZ를 설정하기 위한 제품을 판매하고 있다.

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

보안에서 DMZ란 우리나라에 있는 비무장지대와 같습니다.

말그대로 무장을 하지 않는 다는 것이죠.
그렇다면 왜 무장을 하지 않는가?

그 이유는
주로 DMZ는 방화벽과 연관해서 사용이 되어지는데
기본적으로 방화벽은 네트웍을 보호하는 하드웨어나 소프트웨어입니다.
즉 방화벽은 불법적인 침입에 대하여 필터링을 하는 놈이라고 생각하시면 되겠죠?

그러면 DMZ 를 왜 구성하는가?

그 이유는 바로 서비스에 있습니다.
여러분의 회사나 학교의 네트웍에는 외부로 노출되어야 할 서버나 PC들이 있습니다.
예를 들어 웹서버나 홈페이지 서버, 기타 로긴 서버나 인터넷에서 자신의 네트웍의 서버자원
을 사용해야 하는 서버들이 있겠지요.

그러면 이 서버들을 방화벽 아래에 두게 되면 어쩔수 없이 사용하는 포트를 열어야 합니다.
그렇겠죠? 웹서비스는 HTTP를 열어주어야 하고 FTP서비스는 FTP 포트를 열어주어야 합니다.
이런 식으로 방화벽에 DMZ를 구성하지 않고 서버와 클라이언트PC들을 하나의 네트웍으로 구성하면
보안에 HOLE 이 생길 소지가 있다라는 것입니다.

즉 웹서비스의 열려진 HTTP 포트를 통해서 해킹이 가능해지면 이를 통해 내부클라이언트 PC까지도
손쉽게 해킹이 가능하게 됩니다.

그러므로 DMZ를 구성하게 되는 것이지요.

열어줘야 할 것들은 DMZ를 구성해서 따로 네트웍을 할당 하는 것입니다.
그러면 DMZ에서 로컬 네트웍으로의 침입이 불가능하게 되는 것이죠.

즉

인터넷 -> DMZ : OPEN (필요한 서비스만)
DMZ -> 로컬네트웍 : CLOSE (DMZ 서버를 통해서 로컬네트웍으로의 불법적인 침입 방지)
로컬네트웍 -> DMZ : OPEN (필요한 서비스만)
인터넷 -> 로컬네트웍 : CLOSE (로컬네트웍 보호)

이런 식의 정책적용이 기본적인 방화벽의 DMZ 관련 정책입니다.

가장 기본적으로 DMZ를 구성하는 경우는 아래와 같습니다.

방화벽에 NIC를 3장 달아서
하나는 인터넷, 다른 하나는 DMZ, 나머지 하나는 로컬네트웍으로 연결을 시켜주는 것이죠.

마지막으로 다시 정리해보면
DMZ는 외부에서 엑세스 가능한 서버들의 네트웍을 할당해 놓은 곳이며
DMZ를 구성함으로써 로컬네트웍의 보안을 가져갈 수 있다.

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

간단히 말해 비무장 지대입니다.

네트워크 상에서 여러가지 보안 정책을 쓰지 않는 구역을 말하는데..

물론 방화벽을 걷어 버리는 것은 아닙니다.

하지만, 포트가 다 열리고, 중간에 필터링을 없애는 거죠..

공용네트워크가 있다면, 대게 포트필터나, 방화벽 등등으로 제한들이 걸려 있습니다.

보안상의 문제도 있고, 트래픽 관리상의 목적도 있겠죠..

이러한 네트워크에서 특정 PC 를 DMZ 로 놓게 되면, 포트가 모두 열리게 되고, 필터제한을

일시적으로 제거 할 수 있습니다.

물론 이런건 설정 하기 나름이구요..DMZ 를 한다 하더라도, 불법패킷에대한 방화벽 기능등은

유지가 되구요..물론 이것 역시 설정하기 나름이겠지만..암튼..이런 제한을 풀어버리는 역활을

DMZ 라 합니다.

물론 DMZ 설정을 해 두면 보안상으로 치명적일 수 있겠죠?..

생각 나는대로 적습니다..

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

DMZ 를 세팅하기 위해서는 내부적인 IP 가 고정으로 변환해야 한다는 것이고,
케이블 모뎀이 외부로 부터 연결시켜 주는 IP 는 개인이 임의적으로 설정할 수
없습니다.

또한 케이블 모뎀을 통해서 인터넷이 되는 것이기 때문에, 사용자가 IP 설정에서
임의의 IP 를 설정해 놓는다 해도, 그 IP 로 설정이 되는 것이 아니라, 인터넷
서비스 없체에서 모뎀으로 동적으로 뿌려주는 IP 를 이용하게 됩니다.

따라서 IP 공유기에서 DHCP 사용을 하지 않으시고, 아이피를 192.168.1.x 이런식으로
고정해서 내 컴퓨터에 설정해 주시면 DMZ 사용하는데는 이상이 없을것 같습니다.

추가로, 개개인별로 고정 IP 를 사용하게 되면, 어떤 문제가 있느냐 하고
질문 하셨는데, 인터넷 서비스 없체는 고객의 수만큼 충분한 IP 를 가지고
있지 않고, 그때 그때 필요로 하는 고객에게 IP 를 주는 식으로 효율성을
높이고 있으며, 또 고정 IP 를 주게 되면, 다운로드 위주의 대역폭을 설정해
놓은 모뎀이 개개인들의 서버 사용으로 인해서 업로드 트레픽이 많아 지게되어
전체적으로 속도 저하를 가져 오게 되어서, 고정 IP 를 주지 않는 것으로 알고
있습니다.

도움 되셨길..^^

포트포워딩

포트와 아이피는 별게 입니다.

사실상 특별한 보안상의 문제나 isp 업체에서 해당 포트를 막아 놓지 않은 이상 굳이 포트를 변경할 필요는 없을듯 합니다.

기본 포트가 아니면 다른 사람들이 접속할때 마다 포트를 지정해줘야 하므로 불편하죠. 그냥 기본 포트로 하는 것이 좋습니다.

다만 공유기에서 DMZ 기능을 제공하느냐의 문제입니다.
DMZ 기능이란 공유기에 할당된 ip 주소를 하위 피씨의 사설아이피로 직접 연결해 주는 기능으로, 포트별로 여러대의 피씨에 할당해줄수도 있습니다.

만약 공유기가 DDNS 기능까지 지원한다면, 외부에서 접속할때 수시로 바뀌는 아이피 주소가 아닌 업체에서 할당받은 도메인 명으로 항상 접속 할수 있습니다.

아이피 주소는 그냥 현재 상태 그대로 두셔도 됩니다.
가지고 계신 공유기가 외부 관리는 지원하는 것으로 보아 DDNS 까지 지원하지 않을까 싶긴 한데요. 메뉴얼의 dmz 기능과 DDNS 기능부분을 참조하세요.

더 궁금하신 사항은 쪽지로..

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

유동 아이피라 하면 DHCP서버에서 자동으로 아이피를 할당 받는 것을 말합니다.

만에 하나 현재 이용하고 있는 초고속 인터넷 서비스가 B&A 같은 사설아이피를 할당받은 네트워크라면 서버 구축이 불가능하나, 공인 아이피를 할당 받았을 경우는 DDNS( Dynamic Domain Name Server) 를 이용해서 구축이 가능합니다.

DNS 는 아이피로 된 피씨의 주소를 도메인 명으로 연결해주는 서비스인데 유동아이피일 경우 DNS에서 질문자의 피씨를 찾을수 없게되기 때문에 DNS 서비스는 불가합니다. 하지만 질문자의 서버에 DDNS 클라이언트 프로그램을 설치해서 수시로 DNS서버로 아이피의 현재 상태를 전송해준다면 서비스가 가능해지죠. 이렇게 클라이언트에서 아이피 정보를 수시로 보내서 갱신하여서 고정된 이름으로 접속 할수 있도록 해주는 것은 DDNS 서비스 라고 합니다.

추가정보로 가정에서 공유기를 통해서 피씨를 서버로 사용하는 것은 불가능하였지만, 요즘 공유기의 기능으로 DMZ 기능을 이용하면 공유기에서 내부에 연결된 사설 아이피의 피씨로 무조건 연결하도록 임의로 설정하여 서버로써의 활용도 가능합니다. 일부 제품에서는 DDNS서비스 까지 무료로 지원해주고 있습니다.

DDNS 서비스는 몇군데 업체에서 하고 있지만 DNS 서버의 트래픽이 적을 수록 본인의 컴퓨터로 연결되는 속도는 빨라집니다. 가입할때 신경을 쓰셔야 할부분입니다.

DDNS 서비스를 이용하면 FTP 뿐만 아니라 웹서버, 터미날 서비스로 외부에서 내 컴퓨터를 직접 작동하여 끄는것등의 작업까지 가능합니다. 

예 할 수 있습니다.
FTP서버를 설치하는데는 유동이든 고정이든 전혀 문제가 없습니다.

여기서 유동이란 말은 그 아이피(서버로 사용하는 컴의 주소)가 자주 바뀔 수 있다는 말이죠. 유동아이피에는 임대기간이라는것이 있습니다. 아이피를 받은 시간으로부터 몇시간동안 똑같은 아이피를 부여하게끔 DHCP 서버에서 지정을 해줍니다. 다시 말해서 오늘 주소는 "10.125.8.115" 였던것이 임대기간이 지난 내일은 "10.125.8.125" 로 바뀌어 버리는 것입니다. FTP 서버(웹서버도 마찬가지 입니다)가 설치되어 돌아가더라도 그 주소를 모른다면 (다른 이들이 찾지 못한다면) 무용지물이겠지요. 해서 유동아이피라면 사용하기가 힘들다는 겁니다. 매번 현재 주소를 사용자들에게 알려줘야 하기때문이죠. 이게 바로 문제점이 되겠구요.

여기에 따른 해결책으로는 아이피를 고정아이피로 바꾸는 방법, 그리고 많은 분들이 말씀하셨지만 네이밍 서비스를 이용하는 방법이 있겠지만 돈이 듭니다(사야하죠).

그밖에 유동아이피를 고정아이피처럼 사용할 수 있는게 바로 포워딩입니다. 조그만 프로그램이 사용하고자 하는 서버 피씨에 상주해서 아이피가 바뀔때마다 (보통 얼마 시간만에 업데이트하라고 정해놓습니다) 포워딩해주는 호스트에 정보를 전달해주지요.
즉, 10.125.8.115 을 abc.no-ip.com 으로 매핑 해놓고 만일 아이피가 바뀌면 바뀐아이피(만약 바뀐주소가 10.125.8.125 이라면)로 또다시 10.125.8.125 를 abc.no-ip.com 이런식으로 매핑을 시켜줍니다. 그래서 외부 사용자들은 abc.no-ip.com 이라는 도메인 하나로 접속이 가능하게 되는 것이지요.

이런 포워딩을 서비스해주는 곳은 많이 있습니다.
http://www.no-ip.com
http://www.codns.com/korean
http://xdns.co.kr
검색사이트에서 유동아이피로 검색 해보시면 많이 찾을 수 있을 것입니다. 개인적으로는 이 방법을 씁니다.

유동 ip를 사용할 경우의 문제점
: ftp서버의 ip가 유동 적으로 변함으로 하여 ftp client가 어떤 ip로 접근해야 하는지를 알 수 없으므로 ftp 서비스가 거의 불가능함

해결방안
: dynamic DNS의 사용
ftp client는 domain name으로 ftp 서버에 접속함
ftp 서버는 유동적인 자신의ㅣ ip를 항상 DDNS(dynamic DNS)서버에 알려줌으로 해서 DNS query가 들어 왔을 때 실시간으로 바뀌는 서버의 ip address를 ftp client에게 알려줌.

DDNS 사용시 필요한 점
: DDNS 서비스를 할 서버가 필요함 ftp서버에는 DDNS client program이 설치 되어 실시간으로 ftp 서버의 ip address를 DDNS 서버에 전송하고 DDNS 서버는 update된 ip address를 DNS의 domain과 매칭 시키는 작업을 함

펌...

http://tunelinux.pe.kr/sysadmin/iskim/linux-window-7.html

7. 기업 환경을 위한 리눅스 블랙박스 만들기[7]

7.1 20만통의 메일과 sendmail

이번달에는 webmin등을 이용한 서버 설정에서 잠시 벗어나 본격적인 서버 설정에 대해서 알아보자. 아무리 기업환경을 대상으로 한다고 해도 리눅스에 대한 개념을 갖추지 못한 사용자만이 있는 것은 아니며 유닉스에 익숙한 관리자들도 많을 것인데 이들은 유닉스에 익숙하고 리눅스를 유닉스 중의 하나로 보고 일반적인 관리방법만을 적용하고 있다. 왜냐하면 현재 인터넷등에서 리눅스에 대한 글은 초보와 중급 정도의 독자를 대상으로 하고 있으며 대부분의 글이 처음 설치와 제대로 동작하기 정도에서 멈추기 때문이다. 여기저기 흩어져 있는 설정 방법들을 모두 섭렵하기에는 관리자들이 시간이 없으며 그런 문제를 전문적으로 해결해 줄 곳도 없기 때문이다. 또한 아무리 오픈소스가 인기가 있고 리눅스 열풍이 한반도를 휘몰아쳐도 여전히 나는 남의 정보를 얻어 오지만 내 것은 줄 수 없다는 생각이 지배적이기 때문이다.

필자는 여기 저기서 특별한 개발이 진행되고 있다는 소식을 주워 듣고는 있는데 제품화가 진행되고 있다는 소리는 있지만 이 것을 공개하고 있다는 이야기는 듣지 못하고 있다. 아무리 리눅스가 바람을 타더라도 이런 상황에서는 아무도 도약할 수 없다. 리눅스 마케팅의 대상은 한국이 아니라 전세계 시장이며 이런 마케팅은 정보의 공개에 의해서 그 힘을 얻을 수 있다. 각자 알고 있는 것을 일단 공개하자. 얻은 만큼 주어야 클 수 있고 보답이 돌아온다는 것을 명심해야 하지 않을까? 이 글은 필자가 대규모 메일 중계 서버를 관리하면서 알게된 경험을 바탕으로 쓴 글이다. webmin으로 하는 서버 설정을 기대하고 이 글을 읽는 독자들에게는 다소 어려운 글이겠지만 나중에는 결국 도움을 줄 수 있는 글이 될 것이다.

한 개의 서비스가 대규모화 되고 소위 엔터프라이즈급의 처리가 가능하기 위해서는 소규모일 때에는 전혀 문제가 되지 않던 것들이 엄청난 문제를 일으키게 된다. 리눅스가 대규모 서버로서 제대로 설 수 있기 위해서는 어떤 것들을 고려해야 하는지에 대해 알아보자. 이 글에서는 메일서버에 대해서만 언급하고 있지만 꼭 그 것에만 국한 된 것은 아니며 웹서버나 삼바등에서도 활용가능하다.

7.2 숙제풀이

지난 달에 sendmail이 가능하면 처리할 메일을 즉시 보내기를 하도록 하는 방법에 대해 물었다. 그 방법은 다양한데 가장 빠른 방법은 실제로 과중한 부담을 받는 메일서버를 관리하면서 고쳐 나가보는 것이다. 숙제의 답은 본문 속에서 찾아 볼 수 있다. 리눅스에서 하루에 20만통의 메일을 전송, 수신, 중계를 해야할 때 생길 수 있는 문제에 대해서 생각하다보면 이 정도의 문제는 쉽게 답을 낼 수 있을 것이다.

7.3 이글의 범위

이 글은 sendmail을 인스톨하고 설정하는 법에 대한 설명이 아니다. 기본적인 설정에 대해서는 언급하지 않는다. 네임서버 설정과 MX 레코드등에 대해서도 언급하지 않는다. 사용자명 재지정을 위한 alias, 수신 메일의 도메인을 처리할 것인가 여부를 결정하는 sendmail.cw, 수신 메일의 도메인과 사용자명을 바꿔치기하는 virtusertable, 변경전의 도메인을 새 도메인과 일치시키는 domaintable, 송신메일에서 사용자와 도메인명을 바꿔치기하는 genericstable, 상태편 사이트의 메일서버 문제를 처리하는 mailertable, 메일을 처리해 주는데 문제가 없는 사이트로 인정하는 sendmail.ct 등에 대해서 구체적으로 언급하지 않는다. 독자적인 sendmail.cf를 만들기 위해서 필요한 m4 프로그램 사용법도 마찬가지이다. 알고 싶으면 /usr/lib/sendmail-cf를 조사해 보기 바란다. 배포본의 설정은 /usr/lib/sendmail-cf/cf/redhat.mc에 들어 있다. m4 사용법은 이 글의 주제가 아니며 자세한 관련 문서가 같은 디렉토리에 있고 인터넷을 통하면 쉽게 한글문서도 구할 수 있다.

이 글에서 언급하는 대부분의 프로그램에 대한 사용법은 알고 있어야 한다. 모른다면 프로그램 예가 나올 때 마다 메뉴얼 페이지를 조사할 것을 권한다. sendmail 자체에 대해서 잘 모르는 사용자들이나 하루에 100개 미만의 메일을 처리하는 서버를 다룬다면 이 글을 읽지 않아도 좋다. 일반적인 sendmail의 옵션을 알고 싶으면 소스에 함께 배포되는 설명파일을 읽던지 인터넷을 뒤지던지 관련 서적을 구입할 것을 권한다. 시스템 설정 과정에 대한 사항도 자세히 설명하지 않는다. 이 글의 목적은 엔터프라이즈급 환경에서 리눅스를 운용할 때, 특히 메일서버로 사용할 때 제기될 수 있는 문제에 대해서 쓰는 글이며 메일서버 설정법에 대한 초보적이고 지루한 강의가 아니기 때문이다.

7.4 필요한 것들

리눅스를 메일서버로 사용하기 위해서는 sendmail 패키지가 필요하다. 물론 대부분의 배포본에는 기본적으로 메일서버가 인스톨되도록 만들어져 있다. 대규모 사이트가 아니라면 기본적인 설정으로 문제가 없다. 대규모 사이트에서 메일분산을 위해서는 sendmail 소스 배포본의 프로그램이 필요하므로 소스도 가져오기 바란다. 자체 네임서버도 필요하다. 배포본의 캐싱만 하는 네임서버를 인스톨해 둘 것. 그외 syslogd와 logrotate, top, killall 프로그램 사용법에 대한 지식도 필요하다. 하드웨어는 하루 전송량 1000통이하라면 팬티엄200, 메모리 64메가정도, 그 이상이라면 팬티엄II-450, 메모리 128혹은 256이상이 필요하다. 서버라면 스카시 하드 디스크를 사용하고 있을 것이다. IDE도 상관없지만 속도가 문제라면 스카시 하드 디스크가 적당할 것이다. 네트웍은 가능한한 빠른 것이 좋으며 트래픽을 감시하면서 메일서버의 처리량이 한계를 넘어가면 네트웍 속도를 업그레이드 하던지 속도에 맞게 메일서버의 처리량을 조절하면 될 것이다.

7.5 1천통의 이메일

하루에 1천통 이하의 메일을 처리하는 사이트가 있다. 사용자들은 윈도우에서 메일을 전송하고 리눅스의 계정으로 메일을 받는다. 사용자는 1-200명 정도이고 각 사용자는 10개 정도의 메일을 주고 받는다. 보내는 메일은 리눅스서버가 중계해 주고 받는 메일은 사용자들이 5분 단위로 pop3나 IMAP으로 가져 간다. 이 정도의 부담이라면 기본 배포본의 설정과 팬티엄 정도의 하드웨어 56K-128K정도의 네트웍 속도에서도 부담이 없다. 한 사람당 메일 쿼타로 5M를 준다면 1G 정도의 하드 디스크 여유가 있으면 된다. 파일서버, 프린터서버, 웹서버로 같이 사용해도 된다. 자체 네임서버를 구축할 필요도 없으며 메일 큐 디렉토리의 크기에도 신경 쓸 필요가 없다. 로그파일도 크지 않을 것이다. 90퍼센트 이상의 사이트에서 이 정도의 부담으로 리눅스를 사용하고 있는데 시스템 관리자도 거의 필요 없고 서버를 구석에 놓고 그냥 쓰면 된다. 정전이 되었거나 무심코 리셋키를 눌러서 하드디스크에 문제가 생기지 않는다면 일년이상 신경쓰지 않아도 된다.

sendmail의 기동은 /etc/rc.d/init.d/sendmail에 의해서 시작된다. 중요부분은 다음과 같을 것이다.

     start)        # Start daemons.        echo -n "Starting sendmail: "        daemon /usr/sbin/sendmail -bd -q1h        echo        touch /var/lock/subsys/sendmail

sendmail은 데몬 모드(-bd)로 큐는 한 시간에 한 번씩 뒤져 보게(-q1h) 되어 있다. sendmail은 메일 접속을 받으면 자식 프로세스를 생성하여 처리하며 1시간에 한 번씩, 전송이 되지 않은 메일을 다시 보내기를 시도한다. 1천통의 메일은 이 방식으로 별 문제 없이 처리가 될 것이다. 이런 시스템 관리자는 복잡한 sendmail에 대해서 신경 쓰지 말고 다른 작업에 시간을 투자하기를 권한다.

7.6 1만통의 이메일

1만통의 메일은 사용자가 500명 정도, 1-2개의 메일링 리스트, 그리고 중계해 주어야 할 윈도우 클라이언트가 50-100대 정도 있게 된다. 한 개의 도메인 전체에 대한 메일을 담당하는 메일서버로 사용하는 경우일 것이다. 기본 설정으로 사용하기에는 몇가지의 문제가 발생한다. 500명의 사용자가 5분에 한 번씩 pop3을 사용하고 큐에는 평균 100통 이상의 메일이 저장되어 있게 된다. 가장 문제가 되는 것은 한 개의 데몬이 주고 받는 메일을 처리하기에는 힘들게 된다. 이제 데몬을 구분하도록 하자. 중계와 수신을 위해서, 그리고 큐에 쌓여 있는 메일을 처리할 두 개의 데몬으로 나눈다.

        daemon /usr/sbin/sendmail -bd         /usr/sbin/sendmail -q30m

수신,전송을 위한 데몬은 몇가지 제한 사항에 따라 메일을 직접 전송할 것인지 큐에 쌓아 놓고 나중에 보낼 것인지 결정한다. 해당 옵션은 /etc/sendmail.cf에 있는데 다음과 같은 것이다.

  # load average at which we just queue messages  #O QueueLA=8  # load average at which we refuse connections  #O RefuseLA=12  # maximum number of children we allow at one time  #O MaxDaemonChildren=12

LA란 Load Average라는 뜻인데 오렐리의 sendmail 책에 보면 복잡한 식으로 설명되어 있지만 경험적으로는 동시에 처리하고 있는 메일 프로세스의 수와 일치하는 것으로 보인다. QueueLA=8이란 현재 처리하고 있는 메일 프로세스의 수가 8개 이상이면 전송을 중단하고 일단 큐에 쌓은 다음에 나중에 처리하라는 뜻이다. 또한 RefuseLA=12란 메일 처리 프로세스 수가 12개 이상이면 접속을 거부하라는 의미가 된다. 마찬가지로 MaxDaemonChildren=12란 한개의 sendmail 데몬이 만들어 낼 수 있는 자식 프로세스의 수를 12개로 제한한다는 뜻이다. 이제 이 값을 바꾸어 준다. 큐에 메일을 쌓지 않고, 네임서버에 의뢰한 결과 보낼 주소가 유효한 것이고 상대편 메일서버가 전송을 허가해 준 메일이라면 즉시 전송을 시도하도록 한다. 그리고 가능한한 지연 없이 메일을 받아 들이고 원하는 모든 접속을 수용할 수 있도록, 접속 거부를 시작할 프로세스 수와 자식 프로세스의 최대값을 큰 값으로 유지한다.

  O QueueLA=128  O RefuseLA=128  O MaxDaemonChildren=64

첫칸에 #가 붙은 것은 sendmail에 설정되지 않으므로 변경하고 싶으면 #를 제거하고 값을 바꾸어 준다. 이제 sendmail은 동시에 128개(수신, 중계 sendmail 64, 큐처리 64)까지 뜰 수 있다. 수신메일은 최대 64개 까지 동시에 처리되며 중계나 수신은 64개 까지는 거부없이 받아 들인다. 물론 메일 거부는 부하가 많이 걸릴 때 발생하며 상대편 메일서버는 이 때에 메일 전송에 실패하지만 잠시 후에는 접속이 가능하게 되기 때문에 일시적 메일 서버 접속 거부는 아무런 문제가 없다. 잘못된 주소로 메일을 보내거나 이 메일 서버가 전송을 시도하는 상대편 메일서버가 다운되어 메일을 보낼 수 없을 때만 메일이 큐에 쌓인다. 큐에 쌓인 메일은 큐처리 전용의 메일서버가 계속해서 전송을 시도하게 되며 정말로 갈 수 없는 메일이 아니라면 몇 시간 안에 메일은 보내지게 될 것이다. 한 개의 메일이 계속 전송이 불가능 할 때 최대로 큐에 저장될 수 있는 값은 5일이다. 그 후에는 큐처리 메일서버가 이 메일을 강제로 삭제하게 된다. 이 값은 sendmail.cf에 있으며 바꾸기를 원하면 직접 찾아 보기 바란다.

7.7 5만통의 이메일

5만통의 메일을 주고 받게 되면 sendmail이 아닌 다른 부분에서 문제가 발생한다. 우선 수신, 중계 전용의 sendmail이 serial하다는 것이 문제가 된다. sendmail은 메일을 수신하면 이 메일이 로칼에 있는 사용자에게 오는 메일인지 중계를 해야 하는 것인지 판단해야 한다. 중계를 해야 하는 것이라면 네임서버에게 헤더에 적힌 메일 주소값을 보내 실제 숫자 IP 주소로 바꾸어 줄 것을 요청한다. 그 동안 이 프로세스는 다른 메일은 받아들이지 않는다. 또다른 메일을 받아들이기 위해서는 자식 프로세스가 fork되어야 하고 64개의 메일 프로세스는 각각 네임서버에게 주소값을 의뢰하는 시간 지연이 있다. 네임서버가 신속히 반응하지 않으면 그 프로세스는 최대 5분까지 1개의 메일 때문에 대기해야 한다. 그 동안 계속 메일이 전송되면 네임서버의 지연으로 대기하는 프로세스는 제외한 프로세스들이 처리해야 하므로 여러개의 프로세스가 네임서버 지연으로 묶이게 되면 금방 64개의 자식 프로세스가 생성되고 그 이상 생성될 수 없으므로 나머지 전송 메일은 전송 시도조차 할수 없게 된다.

즉 1분에 70개의 메일이 전송되고 그 중에서 5개의 메일이 네임서버 지연으로 묶여 있게 될 때는 그 중에서 59개만 처리되고 대기 메일이 5개, 나머지 6개는 전송 실패를 하게 된다. 상대편 메일 서버는 일정시간이 지나야 메일을 재전송하게 되기 때문에 전송지연이 생기게 된다. 물론 메일을 도착 즉시 읽어야 하는 것은 아니지만 이런 지연으로 인해 중요한 업무를 처리할 수 없게 되면 심각한 일이 아닐 수 없다.

또한 중계를 요청한 메일 주소가 잘못되어 있을 경우에는 5분의 지연이 있게 된다. 그래서 평균적으로 목적지 주소가 잘못된 중계메일이 30%정도의 메일서버 수행 성능 손실을 가져올 수 있다. 서버를 빠른 하드웨어로 대체해도 이 문제는 해결되지 않는다.

정상적으로 전송될 수 있는 메일은 1M 네트웍 환경에서, 크기가 10k 이내라면 3초 안에 네임서버 조회, 상대편 서버와 접속, 사용자 인증, 메일 본문 전송의 모든 작업이 끝나게 된다. 100개의 메일을 300초 동안에 모두 전송 할 수 있음을 뜻한다. 좀 더 빠른 하드웨어와 네트웍에서 같은 메일을 2초 만에 전송할 수 있다면 200초가 걸린다. 그러나 그 중에서 1개의 메일이 잘못되었다면 이 메일이 5분(300초)간의 전송 지연을 유발하게 되고 총 걸린 시간은 600(300+300)분과 500(200+300)분의 차이가 된다. 9개의 정상 메일과 1개의 비정상 메일에 대해서 이야기 했지만 1000개의 메일에서 20개의 메일이 이상하다면 총 걸린 시간은 거의 차이가 나지 않는다(11960초와 12940초).

이 문제를 해결하고자 단순히 빠른 서버를 구입한다고 했을 때 하드웨어 업그레이드에 비해서 전송효율이 같은 비율로 올라가는 것은 아니다. 이 것은 마치 99미터를 1초만에 달리고 나머지 1미터를 10초에 달리는 선수와, 99미터를 2초에 달리고 나머지를 같은 10초에 달리는 100M 경주와 비슷하다. 평균적으로 빠르지 않으면 결과는 차이가 거의 없는 것이다. serial 방식의 메일 전송의 병목은 시스템의 수행 성능이 아니라 잘못된 메일이 점유하는 프로세싱 타임에 있다.

5만통의 메일을 처리하기 위해서는 이런 serial 문제를 해결해야 한다. 수신, 중계 메일은 메일을 받아들이는 순간에는 네임서버에 유효한 주소인지 의뢰하는 등의 지연을 가져올 수 있는 모든 행위를 하지 않도록 하고 무조건 메일을 큐에 쌓도록 하는 것이다. 큐에 쌓인 메일은 큐 처리 전용의 메일서버가 병렬적으로 메일을 전송할 수 있도록 만든다.

        /usr/sbin/sendmail -bd -ODeliveryMode=defer        /usr/sbin/sendmail -q1m -OMaxDaemonChildren=64

DeliveryMode는 4가지가 있다. 각각은 sendmail 책에 있으므로 관심있는 사용자는 찾아 보기 바란다. 그 중에서 defer 모드는 수신 메일을 그 즉시 직접 전송을 하지도 않을 뿐 아니라 받은 메일이 유효한 것인지 네임서버에 의뢰하는 등의 시간지연이 있을 수 있는 행위를 전혀 하지 않고 큐에 쌓기만 한다. -q1m란 큐처리 데몬은 1분 단위로 자식 프로세스를 만들고 이 프로세스가 처리할 메일이 있는지 확인하게 하는 것이다. 메일이 큐에 없을 때는 자식 프로세스가 뜬 후에 처리할 메일이 없음을 확인하고 스스로 죽게 된다. 만약 메일이 많이 수신되어 큐에 메일이 쌓이기 시작하면 1분에 한 번씩 큐 전용 메일서버가 자식 프로세스를 만들어 내고 이 들은 각자 메일 전송을 시작한다.

64개의 메일 프로세스가 뜨기까지는 64분이 걸리는데 처음 뜬 프로세스가 1분에 2개의 메일을 처리한다고 하면 평균적으로 64분 동안 64개의 프로세스가 각각 64개의 메일을 처리하는 것이다. 즉 수신 메일이 분당 32개의 메일을 큐에 쌓는 정도의 부하(하루 총 메일량 46080개)에서는 평균적으로 큐처리 메일이 32개 정도가 뜨게 된다. 수신 전용의 데몬은 평균 10개 이내로 떠있게 되는데 그 이유는 한 개의 메일을 단순히 큐에 쌓는 행위는 거의 시간이 걸리지 않기 때문에 뜨는 즉시 메일을 처리하고 죽게 되기 때문이다.

그러나 이런 수치상의 결론이 실제와는 일치하지 않는데 그 이유는 전송될 수 없는 메일이 큐에 쌓이게 되면서 전체적인 성능을 떨어뜨리기 때문이다. 64분 동안 주소가 잘못된 1개의 메일은 각각의 프로세스가 1번씩 전송을 시도하므로 총 64번 시도된다. 전송될 수 없는 메일은 한 개의 프로세스를 5분동안 잡아 놓고 있으므로 10개의 메일이 전송될 수 없도록 하는 효과가 있고 64개의 프로세스에 대해서는 640개의 메일을 보낼 수 없도록 하는 것이다. 하루 동안 계산하면 총 15000여통의 메일을 보내지 못하게 만드는 결과를 낳는다. 한 개의 메일은 5일 동안 살아 있으므로 이런 메일이 다른 방식으로 처리되지 않는다면 메일서버는 엄청난 비효율에 시달려야 한다. 나중에는 큐에는 거의 이런 악성 메일로만 가득차 있고 정작 바로 보낼 수 있는 메일이 이들 속에 묻혀 전송이 되지 못하고 그대로 쌓이는 것을 보게 될 것이다.

sendmail의 소스 배포본의 contrib 디렉토리에는 이 문제를 해결하는데 도움을 주는 프로그램 re-mqueue.pl이 있다. 이 프로그램은 perl로 만들어져 있으며 어떻게 사용하는지는 그 프로그램 안에 자세한 설명이 있다. perl과 관련한 사항은 설명하지 않는다. 소스를 보고 어떻게 활용할 것인지는 스스로 판단하기 바란다.

큐에 쌓이는 메일은 방금 받은 메일과 1시간 전에 받았지만 아직 처리 되지 못한 메일, 그리고 여러 시간 혹은 며칠 전에 받았지만 전송할 수 없는 메일들이 함께 들어 있다. 우선 1-2시간 안에 모든 메일은 큐 처리 데몬이 한 번씩 전송을 시도하기 때문에 1-2시간 전에 받았지만 아직 한 번도 전송이 시도된 적이 없는 메일은 없다고 가정한다. 그러므로 cron을 돌려서 2시간(64개의 데몬이 각각의 메일 전송을 2번 시도한 시간)안에 처리되지 못한 메일은 일차 큐에서 분리하여 다른 큐에 보내고 이 이차큐에 있는 메일을 처리하는 sendmail 데몬을 돌려서 그 메일들을 전송 하도록 한다. 우선 데몬을 다른 방식으로 띄운다.

        /usr/sbin/sendmail -bd -ODeliveryMode=defer        /usr/sbin/sendmail -q1m -OMaxDaemonChildren=64 \                           -OQueueDirectory=/var/spool/mqueue        /usr/sbin/sendmail -q10m -OMaxDaemonChildren=32 \                           -OQueueDirectory=/var/spool/mqueue2

/var/spool/mqueue2를 만들고 여기에는 2시간이 지난 메일을 처리하는 데몬을 최대 32개 까지 띄울 수 있도록 한다. 전송 지연이 있는 메일은 문제가 있는 것이므로 새로운 프로세스는 10분 정도의 시간 간격으로 뜨게 하면 별로 시스템 부담이 없게 될 것이다.

이제 mqueue의 일차 큐에서 mqueue2의 이차 큐로 메일을 보내는 것은 crontab을 사용해서 처리한다.

 # crontab -e 1-59/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue2 7200

10분 단위로 mqueue에서 mqueue2로 2시간(7200초)가 지난 메일을 이동시킨다. 이제 일차 큐에는 전송 중이거나 전송을 기다리는 메일들만 남게 되고 악성메일(현재 보낼 수 없는 메일)은 제거되므로 효율이 눈에 띄게 증가하게 된다. redhat-5.2 이상의 설정이 이와 유사하지만 큐디렉토리간의 파일 이동을 위한 프로그램 설정이 되지 않았다. reahat-5.2 이상을 인스톨 했다면 re-mqueue.pl을 사용해 볼 것을 권한다.

7.8 10만통의 이메일

10만통의 메일을 하루에 처리하는 서버는 거의 엔터프라이즈급이라고 볼 수 있다. 하드웨어는 펜티엄II-dual, 메모리는 256M이상이 필요하고 네트웍은 1M급이 되어야 할 것이다. 리눅스의 사용자 계정은 현재 65536명까지 가능하지만 userid를 공유하는 서로 다른 사용자명을 사용할 수 있다. 또한 쉽게 사용자를 추가하고 제거하는 방법이 고려되어야 하고 사용자 인증 자체도 한 번의 메일을 위해서 64K를 뒤지는 비효율적인 방법이 아닌 다른 방법이 사용되어야 한다. 그러나 이 것은 이 글의 주제가 아니다. 10만통의 메일을 주고 받는 서버는 B급 도메인의 메일서버가 될 것인데 이 글에서는 계정 사용자보다는 주로 하위 클라이언트의 메일 중계를 중심으로 설명한다.

10만통의 메일을 처리하는 서버는 또다른 문제에 직면하게 된다. sendmail은 메일을 전송하면서 그 결과 메세지를 syslogd를 통해서 /var/log/maillog에 저장한다. /var/log/maillog에는 pop3를 사용하여 클라이언트가 메일을 가져가는 기록과 한 개의 메일이 전송될 때마다의 기록을 남긴다. maillog는 cron 이 작동하여 한 주마다 크기를 줄이게 되어 있다(/etc/logrotate.conf참조). 그 크기를 계산해 보자. 아래는 성공적으로 메일 중계가 이루어진 한 개의 메일에 대한 로그이다.

Apr xx xx:xx:xx mail sendmail[24543]: XAA24543: from=<xxx@xxx.com>, \ size=2909, class=0, pri=32909, nrcpts=1, \ msgid=<45672:phj650:99xxxx_23:45:57>, proto=SMTP, relay=[210.108.5.10]Apr xx xx:xx:xx mail sendmail[24543]: XAA24543: to=<xxxxx@xxxmail.net>, \ delay=00:00:00, mailer=esmtp, stat=queuedApr xx xx:xx:xx mail sendmail[26062]: XAA24543: to=<xxxxx@xxxmail.net>, \ claddr=<xxxxxxx@xxxinc.com> (504/504), delay=00:09:27, xdelay=00:00:01,\ mailer=esmtp, relay=r-xxxxx.xxxmail.net. [xxx.xxx.152.76], \ stat=Sent (AAA06884 Message accepted for delivery)

한 개의 정상적인 메일이 전송될 때 나오는 메세지는 560여 바이트가 된다. 이 것은 정상적으로 전송된 메일의 경우에만 그렇고 여러가지 이유에 의해서 전송되지 않는 메일은 하루에 여러번 전송 시도를 하기 때문에 여기에 더해서 그 때마다 에라 메세지가 쌓인다. 그러므로 평균적으로 한 개의 메일이 1k정도의 메세지를 뿌린다고 하자. 하루에 10만개의 메일을 전송하니까 로그는 100M가 된다. 일주일 동안 로그 파일의 크기는 700M로 커진다.

메일계정이 1000명이라고 할 때 각각의 사용자가 5분마다 한 번씩 메일을 체크한다. 한 번의 메일 체크 로그는 아래와 같다.

Apr xx xx:xx:15 mail ipop3d[22650]: port 110 service init from 210.xxx.x.xApr xx xx:xx:18 mail ipop3d[22650]: Login user=xxxxx host=[210.xxx.x.xx] nmsgs=7/7Apr xx xx:xx:24 mail ipop3d[22650]: Logout user=xxxxx host=[210.xxx.x.xx] nmsgs=0 ndele=7

한 번에 약 0.2k의 로그가 쌓인다. 윈도우에서 pop3을 사용해 메일을 가져가고 근무 시간 이후에는 컴퓨터를 끈다고 가정하면 하루에 8시간 근무하는 사용자는 192K의 로그를 만들어 내고, 1000명은 192M를, 일주일에는 1.3G의 로그를 생성시킨다. 메일 서버에 하드 디스크가 넉넉하다면 로그 파일의 크기가 커지더라도 하드 디스크 용량 때문에 문제가 생기지는 않을 것이다. 한 사용자당 5M씩 할당하면 메일을 저장할 영역으로 5G가 필요하고 로그를 위해서 2G이상이 필요하다(logrotate값이 4라면 8G.)

문제는 여기에 있지 않다. syslogd는 한 개의 파일, maillog를 열어 놓고 계속해서 로그 메세지를 쌓게 되는데 이 때 1M이상을 넘어가면 1개의 로그 메세지를 처리하기 위해서 시스템 자원을 10 퍼센트 이상 사용하며, 10M를 넘어가면 40 퍼센트 이상, 100M 메가를 넘어가면 거의 80퍼센트 이상의 시스템 자원을 사용하게 된다. 로그 파일이 커질 수록 점점 시스템 자원이 고갈 되어서 나중에는 메일 전송 보다는 로그 쓰기 작업에 모든 프로세싱 타임을 사용해야 한다. 아래의 예는 /usr 파일을 백업하기 위해 사용한 tar에서 부르는 gzip이 시스템 자원을 79.4 퍼센트를 사용하고 있음을 보여주는 예이다.

    x:xxxx  up 1 day,  2:05,  2 users,  load average: 0.22, 0.05, 0.02  49 processes: 46 sleeping, 3 running, 0 zombie, 0 stopped  CPU states: 78.6% user,  5.7% system,  0.0% nice, 15.8% idle  Mem:  192896K av, 189948K used,   2948K free, 283288K shrd,  12496K buff  Swap: 104416K av,      0K used, 104416K free                133384K cached    PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND   4688 root      11   0   580  580   232 S       0 79.4  0.3   0:06 gzip   4687 root       4   0   532  532   432 R       0  3.9  0.2   0:00 tar   4689 root       2   0   708  708   548 R       0  0.9  0.3   0:00 top

지금 여러분의 시스템에서 top 명령을 사용해 보기 바란다. 시스템 자원을 10퍼센트 이상 사용하고 있는 프로세스가 있다면 필시 하드 디스크를 접근하고 있는 프로그램일 것이다. 컴퓨터에서 하드 디스크를 빈번하게 사용하는 작업이 여러개 떠 있다면 성능은 급격하게 하락하게 된다. 메일서버 뿐만 아니라 웹서버와 같은 데몬들의 성능이 느려 졌다면 필시 이런 문제가 개입되어 있을 확률이 높다.

배포본에 있는 로그 파일 처리는 하루에 10만개의 메일을 처리하기에는 역부족이다. 좀 더 효율적인 처리를 생각해 보자. 우선 아래 파일을 만든다.

  /etc/logrotate.mail  daily  size 100k  rotate 2  errors root  create  /var/log/maillog {    postrotate        /usr/bin/killall -HUP syslogd    endscript  }  /var/log/messages {    postrotate        /usr/bin/killall -HUP syslogd    endscript  }

maillog, messages 외에 /var/log에 있는 파일 중에서 시간 별로 그 크기가 1M 이상씩 증가하는 것이 있다면 여기에 첨가한다. 로그 파일은 가능한한 작게 유지하는 것이 좋다. 위에서 로그 파일의 크기가 100k 이상이 되면 무조건 작게 만들도록 설정을 했다. 로그를 줄일 때 이전 로그는 log.1이 되고 log.1은 log.2가 된다. 여기서 rotate를 2로 만들었기 때문에 log.2는 삭제되고 log.1은 log.2가 되며 log는 log.1이 되고 새 파일 log가 만들어져 syslogd가 여기에 쓰기를 한다. cron 작업은 다음과 같이 설정한다.

   #crontab -e   1-59/10 * * * * /usr/sbin/logrotate /etc/logrotate.mail

10분 마다 로그를 점검하여 그 크기를 줄인다. 이렇게 10분마다 로그처리를 위해 프로세싱 타임을 소모하더라도, 로그의 크기를 줄여서 얻는 효과가 더 크기 때문에 빈번한 로그 처리 작업에 드는 프로세싱 타임을 상쇄하고 남는다. 여러분의 웹서버가 오래 켜 놓으면 시간이 지날 수록 점점 느려지는 이상한 증상은 없는가? 이런 증상 때문에 메모리를 늘이거나 대용량의 하드웨어를 구입할 계획을 세우고 있었다면 /var/log/httpd 디렉토리를 점검해 보기를 바란다. access_log가 10M 이상은 아닌가?

10만통의 메일을 처리하는 서버에는 일차큐에 시간당 5천통의 메일이 쌓인다. 이제 64개의 메일 프로세스로는 감당을 할 수 없다. 한개의 메일은 2시간 동안 큐에 대기하게 되는데 2시간 동안 1만통의 메일이 쌓이게 되므로 그 동안에 각각의 메일을 처리 할 수 있을 확률이 낮아 진다. 이렇게 64개의 큐처리 메일 서버가 동작하면서 두시간 안에 모든 메일을 한 번씩이라도 전송 시도 하기가 어려워지는 상황에서 더욱 상황을 나쁘게 만드는 것은 5퍼센트(500개)악성메일이 프로세싱 타임을 늘게 만드는 것이다. 이 문제를 해결하기 위해서 다음과 같은 방법을 사용할 수 있다. 즉 최대 자식 프로세스 숫자를 높이고 각각 다른 제한을 가진 프로세스를 띄운다.

        /usr/sbin/sendmail -bd -ODeliveryMode=defer        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue \                           -OMaxDaemonChildren=96 \                           -OTimeout.initial=1m -OTimeout.connect=1m \                           -OTimeout.iconnect=1m -OTimeout.helo=1m \                           -OTimeout.mail=1m         /usr/sbin/sendmail -q1m -OQueueDirectory=/var/spool/mqueue \                           -OMaxDaemonChildren=16        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue2 \                           -OMaxDaemonChildren=32

mqueue2에는 2시간 안에 처리되지 못한 메일이 있으므로 악성메일이라고 판단하여 프로세스 수를 늘이지 않았다. 일차큐인 mqueue에는 두개의 각기 다른 데몬이 떠 있는데 첫번째 것은 96개까지 자식 프로세스를 만들어 낼 수 있고 두 번째 것은 16개 까지 만들어 낼 수 있다. 시스템에 생길 수 있는 총 메일서버 프로세스의 갯수는 수신 중계 전용(64+1), 일차큐(96+1, 16+1), 이차큐(32+1)로 212개이다. 이 때 쯤이면 각 경우에 맞추어 /etc/sendmail.cf의 변수를 조절해야 한다는 것은 스스로 알게 될 것이다. 지금은 아래와 같이 하면 된다.

  O QueueLA=256  O RefuseLA=256  O MaxDaemonChildren=64

mqueue에 실행되는 두 개의 각기 다른 큐전용 메일 프로세스의 차이는 무엇일까? 우선 한 개는 네임서버 그리고 상대편 메일서버와 교신하는 시간제한을 모두 1분으로 정하고 실행하도록 했다. RFC1123에 의하면 각각의 시간제한은 5분으로 설정하도록 되어 있지만 정상적인 메일은 거의 1분이 되기 전에 상대편과 교신하고 메일 본문 전송에 들어가게 되므로 초기 교신 과정에서 1분 이상의 시간 지연이 있으면 느린 네트웍에 있는 메일서버라고 판단하거나 상대편이 전송 불능 상태라고 간주하여 메일 전송을 중단하고 신속히 다음 메일을 처리하도록 한다.

이 프로세스는 10초 마다 한 개씩 자식을 만들게 되므로 메일이 쏟아져 들어오기 시작한 지 960초(16분)이 지나면 96개의 자식 프로세스가 전송이 되든 안되든 1분 안에 1개의 메일을 처리할 수 있으므로 한 시간에 들어오는 5000개의 메일과 거의 비슷한 양의 메일을 처리 할 수 있게 된다. 즉 각각의 메일을 큐에 쌓은 후에 반드시 한 번 이상의 전송 시도를 할 수 있다는 것이다. 악성 메일이 아니지만 상대편 메일서버의 속도가 느려서 1분 이상의 지연 후에 메일이 갈 수 있음에도 전송을 중단당한 메일이 쌓일 수 있는 문제가 있다. 이런 부적절한 처리를 해결하기 위해서 정상 대기 시간을 가진 16개의 메일 프로세스가 1분 대기 프로세스가 남겨둔 메일을 다시 전송 시도 하도록 하면 된다. 그 때문에 한 개의 큐 디렉토리를 대상으로 하는 두 개의 데몬을 띄운 것이다.

두 시간 동안 모든 메일은 최소한 한 번의 전송 시도를 할 수 있게 되며 그럼에도 전송되지 못하고 남겨진 악성 메일은 2차 큐로 이동된다. 일차큐는 항상 효율적으로 사용할 수 있다.

7.9 20만통의 메일

20만통의 메일을 한 개의 큐 디렉토리에 받게 되었을 때 시간당 약 1만통의 메일이 쌓인다. 일차큐에 있는 메일은 2시간 후에 이차큐로 옮겨지기 때문에 2시간 동안 약 2만통의 메일이 쌓이게 되고 메일 전송 효율이 70 퍼센트라면 일정 시점에 큐에 쌓이는 파일의 수는 약 6000개이다. 한 개의 메일은 dfxxxxxx라는 메일 본문과 qfxxxxxx라는 헤더 부분이 각각의 파일로 존재하므로 12000개의 파일이 한 개의 디렉토리에 생성되고 전송 중임을 나타내는 xfxxxxxx라는 파일이 최대 112개가 생긴다. 한 디렉토리에 12112개의 파일이 있다면 그 중에서 한 개의 파일을 열기 위해서는 허용하기 힘든 시간을 소모해야 한다. 지금 한 디렉토리에 10000개의 파일을 만들고 ls 라고 실행해 보기 바란다. 아마 10초 이상의 시간을 기다려야 겨우 그 결과를 볼 수 있을 것이다.

이제 큐에 쌓인 메일 파일의 갯수가 병목이 된다. 한 시간에 1만통의 메일이 쌓인다면 10분에 평균 1700개의 메일 즉 3400개의 실제 파일을 한 디렉토리에 생성하는 것이다. 물론 생성되는 순간에 즉시 전송 되는 경우가 많겠지만 여전히 프로세싱 타임은 한계를 넘어 가게 된다.

이를 위해서는 6개의 큐디렉토리를 새로 만들고 매 10분 마다 각각의 디렉토리에 파일을 옮겨서 전송을 시도하는 것이 좋다. 다음과 같이 할 수 있을 것이다.

        /usr/sbin/sendmail -bd -ODeliveryMode=defer        # 일차큐        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue \                           -OMaxDaemonChildren=32 \                           -OTimeout.initial=1m -OTimeout.connect=1m \                           -OTimeout.iconnect=1m -OTimeout.helo=1m \                           -OTimeout.mail=1m         /usr/sbin/sendmail -q1m -OQueueDirectory=/var/spool/mqueue \                           -OMaxDaemonChildren=4        # 이차 큐 1번        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue_1 \                           -OMaxDaemonChildren=16 \                           -OTimeout.initial=1m -OTimeout.connect=1m \                           -OTimeout.iconnect=1m -OTimeout.helo=1m \                           -OTimeout.mail=1m         /usr/sbin/sendmail -q1m -OQueueDirectory=/var/spool/mqueue_1 \                           -OMaxDaemonChildren=4        # 이차 큐 2,3,4,5번        ....        # 이차 큐 6번        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue_6 \                           -OMaxDaemonChildren=16 \                           -OTimeout.initial=1m -OTimeout.connect=1m \                           -OTimeout.iconnect=1m -OTimeout.helo=1m \                           -OTimeout.mail=1m         /usr/sbin/sendmail -q1m -OQueueDirectory=/var/spool/mqueue_6 \                           -OMaxDaemonChildren=4        # 3차 큐 : 2시간 지난 메일 처리        /usr/sbin/sendmail -q10s -OQueueDirectory=/var/spool/mqueue2 \                           -OMaxDaemonChildren=32

cron은 다음과 같이 구성할 수 있다.

 # crontab -e  0 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_1 600 10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_2 600 20 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_3 600 30 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_4 600 40 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_5 600 50 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue /var/spool/mqueue_6 600 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_1 /var/spool/mqueue2 7200 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_2 /var/spool/mqueue2 7200 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_3 /var/spool/mqueue2 7200 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_4 /var/spool/mqueue2 7200 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_5 /var/spool/mqueue2 7200 1-50/10 * * * * /usr/sbin/re-mqueue.pl /var/spool/mqueue_6 /var/spool/mqueue2 7200

각 디렉토리는 최대한 3000개의 정도의 메일을 보유하게 된다. 일차큐에서는 한 개의 메일에 대해서 최대 10분 동안 전송을 시도한 후에 전송에 실패했거나 미처 처리하지 못하고 남은 것은 각각 10분 단위로 다른 큐로 보내진다. 옮겨진 각 큐에서 2시간을 시도해 본 후에 전송이 되지 않았으면 6개의 이차큐에 남은 메일은 모두 mqueue2로 보내진다. 여기서 2시간 지난 후의 소위 악성 메일에 대한 또다른 처리는 고려하지 않았다. 모든 큐 디렉토리의 부하를 줄이기 위해서는 re-mqueue.pl을 사용하여 2,4,8시간 1,2,3,4일 단위의 큐를 따로 생성하는 것이 좋을 것이다.

위와 같이 했을 때 최대로 뜰 수 있는 메일 서버 프로세스의 갯 수는 268개이다. 이제 시스템에서 처리할 수 있는 프로세스 갯수와 열 수 있는 오픈 파일의 갯수가 문제가 된다. 기본적으로 한 개의 sendmail 프로그램이 기동하면서 여는 파일은 다음과 같다.

   0 -> /dev/null   1 -> /dev/null   2 -> /dev/null   3 -> /var/spool/mqueue/qfVAA14282   4 -> socket:[590]   5 -> /etc/mail/aliases.db   6 -> /etc/mail/access.db   7 -> /etc/mail/virtusertable.db   8 -> /etc/mail/domaintable.db   9 -> /etc/mail/genericstable.db  10 -> /etc/mail/mailertable.db  11 -> /var/spool/mqueue/xfVAA14282  12 -> /var/spool/mqueue/dfVAA14282  13 -> socket:[814754]

이 자료는 ps를 실행하고 현재 전송 중인 메일의 프로세스 번호(예를 들어 235번)에 따라 "ls -l /proc/235/fd" 라고 실행하면 볼 수 있다. 268개의 메일 프로세스가 각각 13개씩의 파일을 열면 모두 3484개의 파일이 열린다. 서버에는 메일 데몬만 떠 있는 것이 아니므로 실제로 열려 있게 되는 파일 수는 이 값을 훨씬 넘어 간다. 현재 리눅스에서 동시에 열 수 있는 파일의 디폴트값은 4096이다. 그 값은 아래의 파일에서 정의되어 있는데 이 것을 고치고 커널을 재컴파일 하면 변경 가능하다.

   /usr/src/linux/include/linux/fs.h     #define   NR_FILE    4096

같은 헤더 파일에 한 개의 프로세스가 열 수 있는 파일의 최대값(NR_OPEN)이 1024로 정해져 있는데 이 값은 변경하지 않아도 좋다. 물론 원하면 변경해도 된다. 그 결과는 각자 테스트 해 볼 것. NR_FILE과 NR_OPEN을 크게하면 주기억장치가 크지 않은(64M이하) 시스템의 경우에는 부팅도 불가능하게 되니 주의 할 것.

커널 컴파일이 귀찮다면 동적으로 이 값을 변경해 줄 수도 있다. /proc/sys/fs/file-max가 그 것인데 아래 명령으로 현재의 최대값과 할당된 값을 볼 수 있다.

   # cat /proc/sys/fs/file-max   4096   # cat /proc/sys/fs/file-nr   1143  274 4096   # cat /proc/sys/fs/inode-max   12288   # cat /proc/sys/fs/inode-nr   8340 34

이들 값의 의미와 읽는 방법은 /usr/src/linux/Documentation/proc.txt를 참고할 것. 커널 컴파일 없이 시스템에서 열 수 있는 최대값을 변경하기 위해서는 다음 명령을 사용하면 된다.

   echo 8192 >/proc/sys/fs/file-max   echo 24576 >/proc/sys/fs/inode-max

inode-max값은 file-max값의 3배수 이상으로 하라고 proc.txt에서 조언하고 있다. 항상 이렇게 하고 싶으면 /etc/rc.d/rc.local에 적어 두면 될 것이다.

메일서버가 200개 이상 뜨거나 웹서버가 동시에 400개 이상 떠있어야 하는 대형 사이트에서는 최대값을 크게 하는 것이 최종적인 해결책일 수 있다. 그러나 이렇게 최대값을 크게 하여 문제를 해결하기 이전에 가능한 현 상태에서 최적화에 우선 신경을 쓰는 것이 더 좋은 방법이다. 왜냐하면 최대값 증가는 더많은 메모리를 요구하고 더 많은 자원 할당을 요구하기 때문이다. 200개 이상의 sendmail을 위해서 쓸 수 있는 최적화 방법으로는 한 개의 sendmail이 여는 파일의 갯수를 줄이는 것이다. 위에서 보듯이 virtusertable.db등은 가상 도메인을 사용하지 않으면 전혀 필요가 없다. 그러나 사용하지 않는 빈 파일인 /etc/mail/virtusertable을 그대로 둔다면 sendmail이 기동하면서 db파일을 만들게 되고 모든 프로세스가 이 파일을 열어 두게 된다. 그러므로 사용하지 않는 파일을 아예 없애버리면 sendmail이 db파일을 만들지 않고, 그에 따라 각 프로세스는 이 파일을 위해 파일 핸들을 할당하지 않으니까 열린 파일 갯수가 줄어든다. 한 개의 열린 파일의 갯수를 줄이면 268개의 파일을 닫는 효과가 있다. 사용하지 않는 domaintable, access, genericsable, mailertable 5개의 파일을 지워버리면 1340개의 열린 파일 수를 절약할 수 있으며 한 프로세스의 열린 파일 갯수가 적어지면 메일을 체크할 때 이 파일을 뒤지지 않아도 되기 때문에 그 만큼 프로세싱 타임이 줄어 들 것이다.

큐에 쌓인 메일을 처리하는 sendmail 프로세스는 메일을 보내기 위해서 네임서버와 교신해야 한다. 메일 서버가 서브네트웍 바깥에 있다면 한 개의 메일을 보내기 위해서 외부까지 교신을 해야 하기 때문에 시간이 많이 걸린다. 한 시간에 1만번의 조회를 시도하면 아마 외부 메일서버도 견디지 못하고 다운될 확률이 있다. 또한 네트웍 자원은 네임서버와의 교신에 모두 소모되고 다른 사람들이 외부로 나가거나 들어오는 것초차 힘들게 된다. 네임서버가 로컬 네트웍의 다른 서버에 있어도 마찬가지이다. 내부 네트웍은 거의 네임서버 접속에 이용되므로 회사 전산망이 마비되고 네임서비스를 하는 서버가 다운된다. 실제로 필자가 내부 네트웍의 다른 서버에 네임서버를 두고 메일서버가 네임 조회를 이 서버 쪽으로 하도록 했었는데 네임서버에 메모리가 고갈되어 named, httpd, cron등이 죽었다. 그 후에 데몬이 죽은 것을 알고 named와 httpd만 살리고 cron이 죽은 것은 알지 못하고 재실행하지 않았더니 cron으로 돌던 log파일 처리 프로그램이 동작하지 않아 로그 파일이 커지는 바람에 시스템이 움직이지 않을 정도로 부하가 걸린 적이 있었다. 필자는 외부에 의한 해킹으로 의심하고 보안관련 문서를 뒤적이느라고 시간을 소비해야 했다. 이렇게 한 개의 메일서버가 연속적으로 다른 서버들에게 영향을 미칠 수 있음을 염두에 두어야 할 것이다.

그러므로 가능하면 메일서버 자체에 메일 전송을 위한 네임서버를 띄우는 것이 좋다. 이 때의 네임서버는 단순한 캐싱만을 하는 네임서버만으로 족하다. 처음에는 네임서버 자체가 외부로 조회를 해야 하기 때문에 시간이 걸리겠지만 계속 사용한다면 중복되는 IP는 같은 메모리 안에서 처리가 가능하기 때문에 외부에 영향을 주지 않으며, 로컬 네트웍의 tcp/ip 자원도 소모시키지 않고 신속한 조회가 이루어 질 수 있다. 캐싱만 하는 네임서버는 간단히 다음과 같이 만들 수 있다.

  /etc/named.conf    options {        directory "/var/named";        check-names master warn;         datasize 20M;  };  zone "." IN {        type hint;        file "root.hint";  };  zone "localhost" IN {        type master;        file "localhost";        check-names fail;        allow-update { none; };        allow-transfer { any; };  };  /var/named/root.hint    #dig >/var/named/root.hint  /var/named/localhost    @  IN  SOA  @ root (                  42              ; serial (d. adams)                  3H              ; refresh                  15M             ; retry                  1W              ; expiry                  1D )            ; minimum       NS     @    1   A     127.0.0.1  /etc/resolv.conf   nameserver 127.0.0.1

이렇게 최소한의 네임서버만으로 네트웍 자원의 낭비를 막을 수 있으므로 20만개의 메일을 처리하기 위해서는 회사내의 공식 네임서버가 있다고 해도 독립적으로 메일서버에 설치하는 것이 좋을 것이다.

7.10 100만통의 이메일 처리를 위하여

소규모 처리를 담당하는 서버에서 대규모 서버로 진화하기 위해서 어떤 것이 필요하고 그 과정에서 중요한 단계마다의 병목은 무었인지 그리고 이 것을 어떻게 해결할 수 있는지에 대해서 알아 보았다. 한 개의 서비스가 커지면 가능한 옵션을 모두 다시 검토하여야하고, 하드웨어 자원을 추가로 요구하며, 로그 파일 처리등의 관련 프로그램의 효율성이 증대되어야 하고, 네임서버와 같은 또다른 서비스까지 자신에게 맞추어 줄 것을 요구한다. 또한 한 개의 서버가 문제를 일으키면 주변의 다른 서버까지 문제가 파급된다는 것도 보았다. tcpdump같이 다른 컴퓨터 사이의 동작을 감시하는 프로그램에 대한 사용법도 익혀 줄것을 부탁한다. 이모두는 서로 보완적이므로 한 개의 서비스를 위해서 그 프로그램만을 들여다 보아서는 안되고 전체를 볼 줄 알아야 할 것이다.

이 글에서는 TCP/IP 포트 재지정에 의한 분산, 메일 전송 정보가 들어 있는 qf* 파일을 분석하여 각각의 전송 실패 이유에 따른 큐디렉토리 분산, 전송할 수 없는 메일에 대한 처리, sendmail.cf의 각각의 옵션에 대한 관찰등은 하지 않았다. 관심있는 독자들은 sendmail 책과 /var/spool/mqueue/qf* 파일에 대해 조사해 보기 바란다.

100만통의 메일을 하루에 처리할 수 있는 초대규모 메일서버는 한 개의 서버로는 한계가 있다. 각각 20만통의 메일을 처리하는 5대의 메일서버가 필요하게 될 것이다. 문제는 이들을 묶어서 단일한 서버로 보이게 하는 방법이 필요하게 된다. 수백대의 서버를 묶어 놓고 IP 라운드로빈 방법을 사용할 수 있다. IP 라운드 로빈은 1.2.3.4,1.2.3.5가 같은 a.b.c.d 도메인명을 가지도록 하고 네임서버 조회 때마다 한 번씩 다른 숫자 IP를 넘겨 주는 방법을 사용한다.

필자가 최종적인 해결책으로 보고 있는 것은 IP-tunneling을 사용한 리눅스 virtual-sever(vs)를 사용하는 것이다. 이 방법은 한 개의 frond-end가 각각의 접속을 받아서 실제 서비스를 하는 back-end 서버에게 접속을 넘겨 주는 것이다. 한 번 접속이 이루어 지고 나서는 client와 back-end간에 직접 접속이 이루어지게 되므로 frond-end는 바로 다음 접속을 처리할 수 있다. vs 리눅스를 개발하는 팀에 의하면 한 대의 frond-end가 1G 급의 부하를 처리할 수 있었다고 한다. 관심있는 사람은 vs홈페이지(http://proxy.iinchina.net/ wensong/ippfvs/)를 방문해 보기 바란다. 최근 외국의 개발업체에서 이 기능을 특화시킨 분산 서버를 제작해서 상업화 시켰다는 이야기도 들은 바가 있다.

이미 리눅스의 메일서버로서의 기능은 신뢰할 만하고 추가 비용이 전혀 필요 없다. 사용자 수 추가에 따라 비싼 라이센스 비용을 지불해야 하는 상용 서버가 설 자리가 없어 지고 있다. 여기에 더해서 사용자 인증, 삭제, 추가 기능을 간편하게 할 수 있는 프로그램이 개발되어 100만통의 메일을 처리할 수 있는 분산 서버와 결합하게 되면 인터넷의 거의 모든 메일서버는 리눅스가 점령하게 될 것이다.

7.11 이 달의 숙제

메일서버와 마찬가지로 웹서버도 많은 히트수를 기록하게 되면 로그 파일이 커질 것이다. /var/log/httpd에 가보았더니 access_log가 30M였다. sendmail을 위해서 설명한 logrotate.conf와 같이 설정 파일을 만들고 하는 것이 시간이 걸려서 잠시 미루고 일단 수동으로 로그 파일을 빨리 정리하고 싶다. 어떻게 하면 될까? 참고로 "rm access_log"라고 해도 로그 파일이 줄어 들지는 않는다. 이건 또 왜 그런 것일까?

####################################
#
# MSN 차단 목록  ...
#
####################################

iptables -t nat -A PREROUTING -s 192.168.1.190 -p tcp --dport 1863 -j DROP
iptables -t nat -A PREROUTING -s 192.168.1.190 -d 207.46.110.0/24 -p tcp --dport 1:65535  -j DROP
iptables -t nat -A PREROUTING -s 192.168.1.190 -p tcp -d 207.46.104.20 --dport 1:65535 -j DROP
iptables -t nat -A PREROUTING -s 192.168.1.190 -p tcp -d 61.100.182.0/25 --dport 1:65535 -j DROP

한줄로 막기...

# 65.54.131.249 <-- https 로  id 인증하는 서버

##### ---- 차단 일 : 2004-07-07 ---- ##########
iptables -t nat -A PREROUTING -s 192.168.1.190 -p tcp -d 65.54.131.249 --dport 443 -j DROP

프로세스 죽이는 몇 가지 방법

ddt       8469  8463  7 20:29 ?        00:01:03 /home/ddt/phoenix/phoenix-bin ddt       8471  8469  0 20:29 ?        00:00:00 /home/ddt/phoenix/phoenix-bin 

초보

$ ps -ef |grep phoenix (눈으로 pid를 확인한다) $ kill pid 

중수

$ ps x |grep phoenix | awk '{print $1}' | xargs kill 

고수

$ pkill phoenix 

물론 고수들이 이렇게 하는지 확인은 되지 않았다

초고수(?)

폐인(?)

# reboot ! 

컴맹(?)

직장상사

어디서 보긴 했는데 어디인지 모름 ㅡㅡ

간단하게 shell 에서 ftp 에 접근할 때 사용하기 좋음..

/tmp 디렉토리에 test.tar.gz 파일이 있을 경우 아래와 같은 스크립트를

만들어 두고 cron 에 등록하면 시간에 맞춰 ftp 에 업로드 됨.

#!/bin/bash

USERNAME=gildong
PASSWORD=1234
HOST=111.111.111.111

PUT_FILES=test.tar.gz

{
        echo user $USERNAME $PASSWORD
        echo bi
        echo prompt
        echo cd log_backup
        echo lcd /tmp
        echo put $FILE_NAME
        echo bye
} | ftp -n -v $HOST > /tmp/log

rsync 의 미러링 기능을 이용한 백업

/***************************************************************/
* rsync 백업 서버 구축에 대해서

Log 파일이 안남아서 첨에 당황함...

proftpd.conf 파일에서...  아래의 부분을 <Global 영역에 설정한 후 로그 생성됨

ExtendedLog      /var/log/proftpd.log ALL  

ALL 은 포맷이당... proftpd 사이트 참고요함..

현재 방화벽 환경 하에서 돌아가는 ftp 인데 "익명 계정" 은 접속을 처음부터 불허하고 있다.

계정사용자만 사용하는데(iptables 에서 허가된 ip 에서만) ftp 에 처음 접속시

로그인 창이 뜰때 까지 시간이 좀 걸리고,

로그인 하고 파일 List 가 뜰때까지 시간이 좀 걸렸다.

proftpd.conf 파일에서 아래와 같이 설정을 추가한 후, 데몬을 다시 시작하니 빨라짐 .. ^^

UseReverseDNS                   off
IdentLookups                    off

FORWARD 로 막으니까 잘 됨..

아직 iptables 에 대한 이해가 떨어져서... 스크립트가 지저분 함..

msn 은 자료전송까지는 잘 되는데... 화상채팅 안되는듯...

아래는 /etc/init.d/iptables 에 저장한 내용...

# nat 로 내부 아이피 이용하기. (192.168.1.0 ~ 192.168.1.255)
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j SNAT --to-source 218.xxx.xxx.xx7

# ftp 허용 (21 번포트)
iptables -A FORWARD -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -p tcp --sport 21 -j ACCEPT
iptables -A FORWARD -p tcp --dport 20 -j ACCEPT
iptables -A FORWARD -p tcp --sport 20 -j ACCEPT

# ssh 허용 (22번 포트)
iptables -A FORWARD -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -p tcp --sport 22 -j ACCEPT

# telnet 허용 (23 번 포트)
#iptables -A FORWARD -p tcp --dport 23 -j ACCEPT
#iptables -A FORWARD -p tcp --sport 23 -j ACCEPT

# SMTP 허용 (25 번 포트)
iptables -A FORWARD -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -p tcp --sport 25 -j ACCEPT

# Time 서버 포트 허용(37 번 포트)
iptables -A FORWARD -p tcp --dport 37 -j ACCEPT
iptables -A FORWARD -p tcp --sport 37 -j ACCEPT

# NickName 허용(43 번 포트)
iptables -A FORWARD -p tcp --dport 43 -j ACCEPT
iptables -A FORWARD -p tcp --sport 43 -j ACCEPT

# Domain 포트 허용(53 번 포트)
iptables -A FORWARD -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -p tcp --sport 53 -j ACCEPT

iptables -A FORWARD -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -p udp --sport 53 -j ACCEPT

# HTTP 허용 (80 번 포트)
iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp --sport 80 -j ACCEPT

# POP3 허용 (110 번 포트)
iptables -A FORWARD -p tcp --dport 110 -j ACCEPT
iptables -A FORWARD -p tcp --sport 110 -j ACCEPT

# ntp 허용 (123 번 포트)
iptables -A FORWARD -p tcp --dport 123 -j ACCEPT
iptables -A FORWARD -p tcp --sport 123 -j ACCEPT

# imap 허용 (143 번 포트)
iptables -A FORWARD -p tcp --dport 143 -j ACCEPT
iptables -A FORWARD -p tcp --sport 143 -j ACCEPT
 

# snmp 허용 (161 번 포트)
iptables -A FORWARD -p tcp --dport 161 -j ACCEPT
iptables -A FORWARD -p tcp --sport 161 -j ACCEPT
 
 
# https 허용 (443 번 포트)
iptables -A FORWARD -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -p tcp --sport 443 -j ACCEPT
 

# rsync 허용 (873 번 포트)
iptables -A FORWARD -p tcp --dport 873 -j ACCEPT
iptables -A FORWARD -p tcp --sport 873 -j ACCEPT

# imaps 허용 (993 번 포트)
iptables -A FORWARD -p tcp --dport 993 -j ACCEPT
iptables -A FORWARD -p tcp --sport 993 -j ACCEPT

# pop3s 허용 (995 번 포트)
iptables -A FORWARD -p tcp --dport 995 -j ACCEPT
iptables -A FORWARD -p tcp --sport 995 -j ACCEPT

# 네이트온 메신저 거부 (5004 번 포트)
iptables -A FORWARD -p tcp --dport 5004 -j ACCEPT
iptables -A FORWARD -p tcp --sport 5004 -j ACCEPT

# MSN 서비스 제어.... 1863 포트
iptables -A FORWARD -p tcp --dport 1863 -j ACCEPT
iptables -A FORWARD -p tcp --sport 1863 -j ACCEPT
iptables -A FORWARD -d 207.46.110.0/25 -j ACCEPT
iptables -A FORWARD -d 207.46.104.20 -j ACCEPT

# 연결된 상태에 대한 수신 허용
# 이 부분 없애니까 FTP 송수신에 문제 생김... 반드시 RELATED 해줘야 함...

# 특정 서비스와 연관된 포트는 허용하는 것 같음...
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# 위에 열어준 서비스 이외의 모든 포트 막기.
iptables -A FORWARD -p tcp -j DROP