수안이의 컴퓨터 연구실

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 03. 에러 로그 분석 방법

웹 서버가 어떻게 사용되고, 혹 잘못된 부분이 없는지를 분석할 때에 유용하게 사용될 수 있는 것 중의 하나가 에러 로그 파일이다. "에러 로그"는 웹 서버가 운영 중에 발생되는 잚소된 모든 기록을 포함하고 있다. 웹 서버의 시작이나 중지와 같은 통보정도에 지나치지 않는 일반 메세지까지 말이다. 에러 로그 파일은 'ErrorLog' 지시어를 이용하여 어느 곳에 기록할 지를 지정하며, 기본으로 설정되는 로그 파일의 경로는 "/usr/local/apache/logs/error_log"가 된다. 에러 로그의 기록을 원하지 않는 경우에는 다음과 같이 "null" 디바이스로 전송하면 된다.



이러한 방법은 웹 서버가 디스크에 엑세스하는 시간을 줄여, 실제로 아파치가 로그를 기록하는데 소비하는 시간을 감소시켜 준다. 이외에 유닉스 시스템 로그 데몬에 에러 메세지를 전송 하는 것도 가능하다. 이것은 한 호스트에 하나의 에러 로그만이 가능하며, 만약 여러 개의 ErrorLog를 지정하게 되면 마지막에 지정된 것이 사용될 것이다. 아파치의 에러 로그는 유닉스 시스템에서 사용하는 것과 같이 제일 하단의 'debug'에서부터 'emergency'까지의 전체 8개의 범위를 가지고 있다.

일반적으로 로그의 모든 메세지들을 에러 로그 파일에 기록하는 것은 디스크의 소모뿐만 아니라 로그를 기록하기 위한 프로세스 시간을 필요로 하게 된다. 이러한 부분들을 고려하여 아파치 웹 서버는 'LogLevel' 지시어를 이용한 각 로그 레벨 단위의 기록이 가능하도록 하고 있다. 예를 들어, 'notice' 또는 그 이상의 범위에 해당하는 내용만 기록에 남기고자 한다면 아래와 같이 입력할 수 있다.


이와 달리, 'debug' 레벨을 선택하게 되면 아파치에서 발생하는 모든 에러 메세지를 로그에 기록하게 되므로 자원의 공간과 프로세스 시간을 낭비하는 결과를 초래하게 된다. 물론 이와 같이 모든 내용을 기록한다는 것이 여러분들에게 어떠한 생각을 줄여 줄지는 모르지만, 'debug'와 같이 모든 내용을 기록한다는 것이 에러 로그에 있어서는 그리 비효율적이라 생각은 들지 않는다. 로그의 범위는 여러분들의 고민으로 남겨 두도록 하겠다.

다음 표는 각 단계별 로그 레벨의 의미를 나타낸 것이다.

로그 레벨	에러의 이미
emerg	불안정한 시스템 상황
alert	즉각적인 조치 필요
crit	중대한 에러
error	비교적 중대하지 않은 에러
warn	경고
notice	중대한 것은 아닌 일반적인 메세지
info	정보
debug	디버그 레벨

아파치의 에러를 시스템 로그 데몬인 'syslogd'를 전송하기 위해서는 다음과 같이 기존의 에러 로그 파일의 이름을 'syslog'로 변경하여야 한다.



기본적으로 에러 로그는 syslog에 'local7'의 이름으로 기록이 되며, syslog.conf에서 syslogd 데몬은 어떠한 에러 메세지들을 받을 것이지 제어하게 된다. syslog.conf에 다음의 라인을 포함하게 되면 /var/log/httpd.log에 내용을 저장하게 된다.



이외에 local7.* 과는 달리 앞쪽에서 언급하였던 로그 레벨을 기반으로 로그를 따로 저장 할 수가 있다. 아래의 예은 warn 로그 레벨 이상의 정보를 /var/log/httpd_warn.log 에 저장하는 것과 info 레벨 또는 그 이상의 메세지를 error 레벨 이하로 기준하여 /var/log/httpd_info.log 에 저장하게 된다. 쉽게 이야기하면 httpd_info.log는 info,notice,warn 레벨을 포함하는 것이다.


웹 서버의 문제 해결은 에러 로그와 함께 아파치를 처음 접하는 초보자가 설치 후 애기치 못한 문제에 봉착하였을 경우에는 당황하지 말고 에러 로그를 찾아봄으로써 문제의 대부분을 해결할 수 있다.

웹 서버에 문제가 있을 때에는 발생되는 문제를 즉시 확인하기 위하여 계속적으로 로그 파일을 확인해 보아야 하는 경우도 있기 마련이다. 이럴 때에는 유닉스에서 제공해 주는 'tail' 명령어를 이용하여 다음과 같이 사용하면 된다.



또 다른 방법으로는 펄을 이용할 수가 있다. File::Tail 모듈을 사용하면 되고 이것을 통하여 여러분들이 다양하게 응용하여 사용해 볼 수 있으며, http://www.cpan.org/modules/by-module/File/File-Tail-0.98.tar.gz에서 구할 수 있다.



"tail -f" 를 이용한 로그 파일을 살펴보면 이래와 같은 내용을 확인할 수 있다.



지금까지 아파치 서버의 대표적인 Access_log와 error_log의 분석 방법에 대하여 알아보았다. 아파치 서버는 오늘날 운영중인 웹 서버중 운영 빈도가 높은 서버중 하나이다.

아파치 서버에 저장된 로그 파일로부터 유용한 정보를 얻어내기 위해서는

- 사용자 스스로 로그 파일에서 필요한 정보만을 추출하는 방법
- 자동화된 로그 분석 프로그램을 이용하는 방법

위 2가지 방법으로 나눌 수 있다. 대부분의 경우에는 수작업에 기록된 내용을 분석하고 통계를 알아내는 방법보다는 분석 프로그램을 이용하여 다양한 정리된 자료를 원할 것이다. 그러나 경영자 입장에서 웹 로그로부터 얻을 수 있는 가장 중요한 정보중 하나는 히트(hit)와 페이지뷰(pageview)이다. 히트는 웹 서버에서 받은 모든 요청과도 같다. 페이지 상에 포함된 이미지, 사운드 파일, 그리고 기타 모든 것들이 하나의 히트로 간주되며, 이와 달리 페이지뷰는 좀 더 정확하게 전체의 각 부분이 아니라 페이지 전체를 하나로 본 것이라 이해하면 된다.

이 히트와 페이지뷰를 통하여 누가 사이트를 방문하였고, 방문한 사용자들은 어디로부터 왔으며, 어떠한 페이지를 보았고, 또 얼마나 오랫동안 머물렀는지, 그리고 사용한 브라우저는 무엇인지 등 다양한 정보를 방문객으로부터 얻어낼 수가 있다.

이러한 정보를 다양하게 분석하려면 분석 툴 보다는 수작업에 의한 것이 더 다양한 정보를 획득할 수 있다는 점을 잊지 말기 바란다. 그러나 로그 분석 툴이 사람의 수작업을 통한 것보다 좀 더 정확하고 신속한 장점도 있음을 알아두자.

아무리 웹 서버의 로그를 잘 분석하고 적절히 조치할 수 있다하더라도 서버 관리자에 의한 환경 설정에 따라 외부로부터의 공격 가능성과 웹 서버 자체 또는 사용하는 어플리케이션 프로그램의 버그로 인한 공격에는 늘 노출되어 있음을 인식하자. 특히 요즘 사회이슈로 자주 등장하는 인터넷 웜의 경우 각 서버에 공통적인 취약점을 찾아서 공격하므로 웹 서버의 경우는 로그 분석만이 아니라 보안 패치가 수시로 이루어져야 한다.

아파치의 경우 공개 소프트웨어이면서 많이 운영되다 보니 시스템 자체의 취약점이 자주 발견되고 즉시 패치자료가 공개되고 있다. 따라서 아래의 사이트에서 수시로 패치자료를 다운받아 설치해두는 점이 좀더 안정적인 시스템 운영에 도움이 되리라 생각한다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 02. 접속 로그 분석 방법

아파치 웹 서버에서 기본적으로 각 클라이언트의 요청을 기록하는 'access_log'는 이름에서도 느낄 수 있는 것처럼 웹 서버에 접근되는 모든 것을 기록하게 된다. 접속 로그는 방문자 정보를 얻는데 있어서 가장 중요한 역할을 담당하고 있다. 우선, 여러분들이 정보를 가져올 'access_log'는 다음과 같이 TransferLog 지시어를 사용하여 어느 위치에 로그를 남길 것인지 결정을 할 수가 있다.
그 러나 1.3.X 버전부터 사용자 정의 로그 포맷을 지원하고 있다. 대부분의 웹 서버들은 CLF(Common Log Format)로 파일을 생성하고 있으며, 이외에도 ELF(Extended Log Format), 그리고 Combined Log Format이 있다. 몇몇 서버들은 이외의 다른 형식 포멧을 사용학 있지만 CLF와 비슷한 형식을 취하고 있으며, 아파치 웹 서버는 기본적으로 이 포맷 방식을 따르고 있다. 지금 시점에서 여러분들이 사용하는 아파치 웹 서버의 로그 파일 설정은 다음과 같이 이루어져 있을 것이다.


CLF는 각 클라이언트 요청에 한 라인으로 구성되어져 있고, 공백에 의해 각 필드는 7가지의 정보를 포함하여 구분되어 있다. 기본 포맷은 다음과 같은 형식을 갖추고 있다.


첫 번째 필드는 원격지 호스트 주소 정보를 가지고 있다. 이것은 어느 누가 여러분들의 웹 사이트를 방문하였는가를 말해주는 것이다. 기본적으로, 이곳은 원격지 호스트의 정보가 IP 주소로 기입이 된다. 물론 아파치 웹 서버에서 호스트 이름을 찾아 기록할 수 있도록 설정할 수는 있으나, 아파치 1.3.X 버전에서는 성능상의 문제로 호스트 이름 대신 IP 주소로 기록하고 있다.


아 파치 웹 서버는 IP 주소 대신 'HostNameLookups' 지시어를 사용하여 호스트 이름으로 기록을 할 수가 있다. 그러나 이러한 방법의 사용은 결과적으로 서버의 전반적인 성능을 떨어뜨릴 수 있는 요인 중의 하나가 될 수 있으므로 권장하지 않는다.

HostNameLookups on과 같이 사용하면 되며, on 이외에 double을 사용하여 역 방향 이름을 찾아 조회하는데도 사용할 수 있다.

logresolve 프로그램을 이용하여 IP 주소를 도메인으로 변경하는 방법은 아래와 같다.


두 번째 필드는 대부분의 경우 아무런 정보를 가지고 있지 않다는 '-'로 표시될 것이다. 이것은 방문자를 식별하는 정보를 얻는 경우에 이용되며, 실질적인 인증을 통한 로그인 이름이 아니라 사용자의 이메일 주소 및 식별할 수 있는 정보 등을 의미한다. 이 정보는 'identd'에 또는 브라우저의 직접적인 정보 제공에 의해 기록되어 질 수 있으나, 이러한 기능은 이미 오래 전에 사라져 사용되지 않고 있는 정보로 생각하면 된다.

세 번째 필드 또한 '-'로 표시되는 경우가 많으며, 방문자가 사용자 인증을 통하여 접속한 경우에 사용자의 로그인 이름이 기록된다. 네 번째 필드는 클라이언트가 서버의 자원을 요청한 시각이며, 다섯 번째 필드 "request"에는 요청한 자원이 어떤 것인지를 나타낸다. 주로 웹 서버의 자원을 클라이언트로 가져가기 위해 GET을 사용하며, 그 다음에는 실제적인 문서, 즉 URL을 의미한다. 클라이언트는 '/'를 시작으로 DocumentRoot 디렉토리로 지정한 경로에 기반하여 사용자에게 문서를 보여주게 된다.

URL의 마지막에는 HTTP 프로토콜 버전이 따라오게 되는데, 이 번호는 1.0 또는 1.1이 될 것이다. HTTP/1.0은 초창기의 프로토콜 버전으로 최근의 브라우저는 HTTP/1.1을 지원하고 1.0에 비해 많은 성능개선을 한 HTTP/1.1이 주로 사용되고 있다.

여 섯 번째의 필드는 웹 서버의 상태 코드를 의미하는 것으로서 클라이언트의 요청이 성공적이었는지, 또는 문제 발생이 있었는지를 코드번호로 나타내고 있다. 대부분의 경우에는 성공적인 전송을 의미하는 200번일 것이며, 서버에서 문제가 발생할 시에는 5XX번대로 시작한 에러코드가 기록될 것이다.

마지막인 일곱 번째 필드는 클라이언트에게 전송된 바이트를 나타낸다. 이것은 하루에 얼마나 데이터가 전송되었는가를 알아내고자 할 때 사용될 수 있다.

다음의 예를 살펴보자.


192.168.0.151 의 IP 주소에서 요청한 것을 보면 2005년 3월 1일 11시 43분 50초에 Test 센터를 요청하였으며 HTTP/1.1 프로토콜을 사용하였다. 상태 코드는 200을 나타내는 것으로 보아 클라이언트에게 성공적으로 전송되었음을 알 수가 있고 총 11,177bytes가 전송되어졌다. 각 필드에 해당하는 의미를 간단하게 기술해 놓은 CLF(Common Log Format)을 구성하는 각 필드는 다음과 같다.

아이템	의미
Host	클라이언트의 호스트 이름이나 IP Address
Ident	IdentityCheck가 enable 되어 있고, 클라이언트가 ident에 응답을 보내면 identity 정보를 남기게 되며, 보통은 "- "로 대체된다.
Authuser	인증이 있을 경우 여기에 사용자 이름이 기록되게 되며, 그렇지 않을 경우 "- "로 대체된다.
Date	접속한 시간과 날짜를 나타내며, 포맷은 다음과 같다 : 날짜 포맷 = [day/month/year:hour:minute:second zone] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (+' | -') 4*digit
Request	클라이언트가 요청한 자료
Status	요청한 것에 대한 서버의 처리 사항으로 상태 코드라 한다.
Bytes	헤더를 제외한 전송된 Byte 양

지금까지 기본 로그 포맷에 대하여 알아보았다. 이번에는 'CustomLog' 지시어를 이용한 사용자 정의 로그 포맷에 대해 살펴보고자 한다.

'CustomerLog' 지시어는 'TransferLog'의 기능을 내포하고 마찬가지로 로그 파일이 어느 위치에 저장되어야 할지를 가리키며 추가적으로 저장되는 로그의 포맷을 사용자에 의해 지정을 할 수가 있다. 이전에는 CLF(Common Log Format)이라 불리는 고정된 형식으로만 사용이 가능하였다. 그러나 지금은 CLF 포맷을 여러분들이 원하는 형태 즉, 필요한 정보로 맞춤 정장과도 같이 여러분들의 입맛대로 만들 수가 있는 것이다.

원하는 형태의 로그 파일을 만들기 위해서는 포맷을 지정하여야 하고, 이 역할을 'LogFormat' 지시어가 한다. 다음의 내용을 httpd.conf에서 찾아볼 수가 있을 것이다.


이 뜻은 인용 부호 "'' 안의 로그 포맷을 "common"의 이름으로 만드는 것이다. 각 문자들이 나타내는 것은 특정 정보를 의미하며, 기술한 순서에 따라 로그 파일에 기록된다. 로그 포맷으로 사용 가능한 변수와 이에 대한 의미는 다음 표와 같다.

포맷	의미
%a	원격지 IP 주소
%A	로컬 IP 주소
%B	HTTP 헤더를 제외하고 전송된 바이트
%b	HTTP 헤더를 제외하고 전송된 바이트. CLF 포맷에서는 전송된 것이 없을 경우 0으로 표시하기 보다는'-'로 표시한다.
%{FOOBAR}e	서버에 의해 지정된 환경변수
%f	파일 이름
%h	원격지 호스트
%H	요청한 프로토콜
%{Foobar}i	Foobar의 내용 : 클라이언트에서 서버로 요청된 헤더라인으로 예를 들자면, Referer 헤더일 경우 %{Referer}i로 사용되어 진다.
%l	원격지 사용자 이름(이것이 사용되어 지기 위해서는 IdentityCheck가 반드시 enable 되어져 있어야 한다.)
%m	요청 방식
%{Foobar}o	서버에서 응답되는 HTTP 헤더. 예를 들면 : %{Content-Type}o, %{Last-Modified}o
%p	요청을 처리하는 서버의 참조적인 포트
%P	현 요청을 처리하고 있는 아파치 자식 프로세서의 프로세스 ID
%q	쿼리 문자열(쿼리가 있을 경우 "?" 뒤로 쿼리문이 포함되며 그렇지 않을 경우 공백으로 처리된다.)
%r	HTTP 메소드를 포함한 요청의 첫 라인
%s	HTTP 상태 코드. 만약 클라이언트의 요청이 내부적인 리다이렉트를 발생시켰을 경우 %s는 초기 요청을 상태 코드를 %>s는 최종 상태 코드를 포함하게 된다. 일반저긍로 %s의 사용 보다는 %>s가 유용하다.
%t	요청한 시간과 날짜(standard english format)
%{format}t	strftime() function을 이용한 포맷 형식에 따른 시간 [Day/Month/Year:Hours:Minutes:Seconds Time Zone]
%T	요청을 처리하는데 걸린 시간(초)
%u	인증이 요청된 원격 사용자 이름
%U	요청된 URL
%v	요청을 처리하는 서버의 참조적인 서버 이름
%V	UseCannoicalName 설정에 따른 서버 이름

여기서 많이 쓰이지 않는 'ident'와 'authuser' 필드는 제거하여 로그 파일에 기록되지 않게 할 수도 있으며, 다음과 같이 에이전트와 참조 로그를 한 로그 파일에 만드는 것도 가능하다.


이와 같이 로그 포맷에 대해서 알아보았는데, 이외에 다른 방법들은 없을까? 'CustomLog'와 'LogFormat'을 이용한 효율적이고도 다양한 방법들로는 무엇이 있는지 함께 알아보도록 하자.

때 로는 HTTP의 각 상태코드 별로 로그를 취합하여 효율적인 분석이 필요한 경우도 있다. 이럴 경우에는 %와 변수 사이에 HTTP 상태 코드를 집어넣어 해당하는 이벤트가 발생하는 경우에 로그를 남길 수 있다. 예를 들어, 잘못된 링크만을 따로 저장하고 할 때에는

LogFormat %404{Referer}i BrokenLinks
CustomLog /usr/local/apache/logs/broken_links BrokenLinks

와 같이 사용하면 된다. 최근에는 멀티미디어 서비스 및 이미지의 사용이 많아지고 있는 추세로 로그 파일에 많은 양의 데이터가 쌓이고 있다. 이에 대한 해결책으로는 아파치의 'mod_setenvif' 모듈을 이용하는 것으로서 방안을 제시해 주고 있다.



(a) - (c) 까지는 gif 이미지를 gif-requests.log에, 그 이외의 것은 nongif-requests.log에 저장 하는 것이며, 나머지 (d) - (g)는 CLF 포맷으로 이미지 파일인 gif를 제외한 로그를 access_log에 남기라는 의미이다.



www.Test.net 을 통해서 들어오게 되면 apache_site_referral 변수를 설정하여 로그를 남길 수도 있다. 한 가지 주의할 점은 SetEnvIf[NoCase]에 의한 환경 변수의 지정은 CustomLog와 같이 변수를 이용한 저장일 경우에는 CustomLog 지시어 전에 설정되어 있어야 한다.

지금까지 여러 다양한 방법의 사용을 알아보았다. 마지막으로 가상 호스트를 많이 운영하는 분들을 위하여 여러 개의 로그 파일을 하나의 파일로 만드는 방법을 보자.


이 것은 기본 로그 포맷 앞에 "canonical name"과 IP 주소, 포트 번호를 나타내는 추가적인 정보가 더 기술되어 있다. 이러한 방식을 통한 운영은 OS 특성상 동시에 파일을 열 수 있는 개수의 제한 등으로 인하여 모든 가상 호스트마다 개별적인 로그 파일을 만들어 줄 수 없을 때 사용할 수가 있다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 01. 웹 로그 분석의 개요

인터넷의 대중화로 한 기업의 이미지를 대표함과 동시에 기업의 생존전략 도구로서 필수불가결한 것 중의 하나가 바로 사용자에게 실질적인 서비스를 제공해 주고 있는 웹 서버이다. 더욱이 시간이 흐르면서 지금의 상황에 반문이라도 하듯이 늘어나고 있는 방대한 양의 컨텐츠와 멀티미디어 서비스 등으로 인하여 인터넷에서의 웹 서버 역할은 날로 중요해지고 있다.

웹 서버를 운영하는 목적 중의 하나는 클라이언트에게 다양한 정보를 제공하는 역할을 수행하는 것이다. 그렇다면 관리자는 이러한 환경의 제공만으로 본연의 역할을 다한 것일까? 어떠한 목적으로의 운영을 결정하였는가에 따라, 이 질문에 대한 대답은 달라질것이며 필자의 입장에서는 클라이언트에게 더 나은 정보 및 환경을 제공하기 위한 방법의 하나로 웹 서버의 단순한 운영만으로는 시스템 운영자 또는 웹 마스터의 역할을 다한것이라고 생각하지 않는다.

한 예로 모 기업의 마케팅 부서 담당자 입장에서 생각해보면, 마케팅 담당자는 그 기업의 생산 계획에서 판매 계획에 이르기까지 전 과정을 체크해야 한다. 여기에 웹 사이트를 이용한 제품 및 여러 가지 홍보 등은 결코 빠질 수 없는 중요한 광고매체로 인식되고 있으며, 대부분의 담당자들은 웹사이트에 기록된 일종의 가공되지 않은 데이터를 원하지는 않을 것이다.

웹사이트를 방문한 사용자들의 정보가 필요로 하는 것에 따라 한눈에 파악하기 쉽도록 만들어지고, 많은 유용한 정보들을 포함하도록 한다면 곧 이러한 정보와 전통적인 데이터들의 통합된 정보는 마케팅적인 면에서 큰 장점을 가지고 있다는 것은 굳이 언급하지 않아도 알 수 있다. 효과적인 광고, 웹사이트에서의 방문자 행동, 구매비율과 같이 총체적으로 이미 분석된 정보를 활용할 수가 있다. 이러한 모든 것들이 현재의 마케팅의 이해와 함께 웹사이트의 분석에 마케팅적으로 이용될 수 있는 부분으로 시장에서 새로운 비즈니스로서 성장하고 있다.

웹 서버의 로그 파일은 초기에 문제의 진단 및 처리량 등의 파악에 이용될 목적으로 디자인되었으나, 지금과 같이 웹사이트의 성능 개선 및 다양한 곳에 이용되리라고는 예상하지 못했다. 현 상에서의 이와 같은 모든 로그 정보들이 웹사이트 운영에 중요한 정보로서 자리매김하였으며, 이는 단순히 접속되는 데이터로 모든 방문객과 모든 페이지에 대해 기록할 수 있게 하여 웹사이트 내에 누군지는 모르지만 수많은 방문객에 관계없이 웹 서버는 바쁘게 움직이고 있다. 이제 필자가 여러분들과 함께 웹 로그의 중요성을 설명한 만큼 아파치 웹 서버에서 제공하는 로그의 이해에 기본을 두고 방문자 정보 분석에 첫 발걸음을 내딛어보자!

01. 어떠한 정보를 이용할 수 있을까?
시작하기에 앞서 여러분들은 웹 서버에서 제공하는 정보로는 어떠한 것이 가능한지 알아야 한다. 아파치 웹 서버는 클라이언트가 요청하는 모든 정보를 로그 파일에 기록하게 되고, 기록된 여러 다양한 정보는 다음을 포함하여 분석을 하게 된다.

1. 원격접근 호스트의 주소
이것은 "누가 나의 웹사이트를 방문했는가" 와도 비슷하다고 할 수 있다. 좀 더 자세히 말하자면, 방문자가 어디에서 접속했는지를 말해준다.

2. 방문횟수 및 시간
방문자가 얼마나 자주 웹사이트를 방문했는가를 알려준다. 주로 오전 9시부터 오후 6시까지의 업무시간 사이에 많은 방문이 이루어진다고 생각할 수 있고, 그렇지 않은 이외의 시간은 집에서의 접속으로 추정할 수가 있다.

3. 요청한 웹 서버의 자원
사이트에서 가장 인기 있는 페이지는 어디일까? 클라이언트가 요청한 자원의 정보를 기록하여 운영자는 어느 부분이 가장 인기 있는 부분이며, 또 그렇지 않은 부분을 판별할 수가 있다.

4. 방문자의 운영체제(Operating System), 브라우저 그리고 브라우저 버전
여러분들의 사이트를 방문하는 사용자가 Mac 또는 PC를 이용한 접속이 몇 %나 될까? 또는 넷스케이프, 인터넷 익스플로러를 이용한 퍼센트는 기본 정보 이외의 'User Agent'정보를 이용하여 방문자의 부가적인 정보를 얻을 수 있다. 위와 같은 정보들은 정확하지 않을 수도 있으나, 완벽히 신뢰하지 못할 만큼은 아니다. 이 뜻은 웹 서버의 로그 자료에만 너무 의존하지 말아야 한다는 점이다. 어떤 페이지에 어느 정도의 사용자가 방문했는지 정확히 알ㄹ줄 수 있을까? 물론 수치상으로 기록된 정보로는 그렇지만, 프록시 캐쉬 등을 이용한 경우에는 웹 서버에 직접적으로 접근하지 않으므로 로그에 기록되지 않을 수가 있다.

비록 이러한 데이터들이 정확하지 않더라도 여러분들의 사이트를 얼마나 방문하는지 등의 대략적인 정보로 사용할 수가 있기 때문에 웹 서버의 로그 파일이 중요한 역할을 한다는 것은 의심할 여지가 없다.

02. 로그 파일은 어떻게 작동되나?
매 시간 웹사이트의 모든 정보는 웹 서버에 의해 파일로 기록된다. 아파치 웹 서버는 이 정보를 접속 로그, 에러 로그 등으로 불리는 다양한 형태로 저장한다. 로그 파일에는 어느 시간에 어떤 페이지를 요청했는지의 기록뿐만 아니라, 클라이언트가 요청한 것에 대한 추가적인 여러 유용한 정보들이 존재한다. 아파치를 설치하면 기본적으로 두개의 파일이 쓰이며, 이중의 하나는 access_log이고, 다른 하나는 error_log이다.

이 파일들은 아파치의 기본 설치에 따라 '/usr/local/apache/logs'에 위치하게 되며, 설정 파일을 통해 로그 파일의 위치는 변경이 가능하다. 이전의 버전에서는 로그 파일이 내용에 따라 다음과 같이 두 가지로 나누어져 있었으나, 현재의 1.3.x에서는 차후 설명할 mod_log_config에 따라 통합적인 방법의 사용이 가능하였다.

• 접속로그
• 에러 로그

접속 로그는 웹 서버로부터 전송되는 정보가 기록되는 것으로 여러 페이지 중의 하나를 방문한 사용자가 어떤 링크를 통하여 혹은 배너를 통하여 접속하게 되었는지의 정보 등을 알 수 있다. 이러한 정보는 여러분들이 방문자의 관심 사항을 간접적으로나마 파악할 수 있게 한다.

아울러 온라인 광고를 하는 경우 이 정보를 이용하여 어느 사이트에 배너 광고를 해야 효율적인가를 결정할 수 있고 더불어 기업의 입장에서는 어떠한 사이트와 좋은 관계를 유지해야 하는가의 판별력에도 도움을 줄 것이다. 클라이언트가 사용한 브라우저에 대한 정보를 에이전트 로그에 기록되며, 웹 서버 운영상에 나타나는 에러 또는 CGI 스크립트 실행 시 발생되는 문제점은 에러 로그 파일에 쓰여진다.

구성이 잘된 디렉토리 구조와 훌륭한 스크립팅 활용하기
Level: Intermediate

Martin C. Brown
프리랜스 작가, 컨설턴트
2004년 9월 14일

한 가지 유형의 시스템을 위한 오픈 소스 애플리케이션을 구현할 때 고려해야 할 점이 많다. 하물며 호환되지 않는 머신 간 분산될 애플리케이션을 구현한다면? 약간의 훈련과 커스텀 스크립트를 사용하면 이 과정을 단순화 할 수 있다. 이 글에서는 애플리케이션들을(과도하게 커스터마이징 된 애플리케이션 포함) 구현하여 분산하는 구조를 만드는 방법과 가능한 한 쉽게, 수동 또는 자동으로, 많은 머신들 간 애플리케이션들을 분산시키는 간단한 방법을 설명한다.
나는 언제나 바이너리나 RPM 배포판을 사용하기 보다는 애플리케이션들을 시스템에 자가구현 했다. RPM을 믿지 못해서가 아니라 많은 시스템들에 커스터마이징 된 환경을 사용하기 때문이다. 디버깅을 바꾸거나 줄여야 할 때도 있을 수 있고, 특정 확장, 모듈 또는 다른 옵션이 필요할 때가 있다. 가끔은 완전히 다른 디렉토리 구조를 만들 때도 있다.

더욱 복잡한 건 Linux™, BSD, OS X, 다양한 사용 UNIX® 배포판을 포함한 오픈 소스 프로젝트를 사용하는 광범위한 플랫폼에서 작업한다는 것이다. 이들 중 어떤 것은 단 하나의 머신을 사용하지만 다른 것은 각종 유형의 10개, 20개 또는 50개 머신을 사용한다. 새로운 소프트웨어가 출시될 때 각 머신을 직접 업데이트 하는 것은 대단한 작업이다. 커스터마이징을 무시하면 실제 구현과 설치 과정은 일반적으로 쉽다. (Listing 1):

Listing 1. 구현과 설치 과정 $ bunzip2 -c latest-release.tar.bz|tar xf - $ cd latest-release $ ./configure $ make $ make install

특별한 교육 없이, 수 백 개의 머신에 직접 수행할 수 있었다. 최신 버전을 섭렵하고 테스트를 목적으로 특정 패키지의 베타와 알파 릴리스로 작업하면서 내가 마치 전문가가 된 듯한 생각을 했다.

몇 년 전, 다음의 간단한 규칙을 따르고 이 프로세스에 구조를 추가하여 프로세스를 뚜렷하게 단순화하기로 결정했다.:

각 OS용 디렉토리 만들기
각 OS 디렉토리 안에 소프트웨어 패키지를 위한 디렉토리 만들기
각 릴리스용 디렉토리 만들기
각 OS를 위해 한번만 구현하기
각 머신에 여러 번 전개하기
네트워크를 통해 공유할 수 있는 모든 소프트웨어에 맞는 구조를 구현하여 시작할 수 있다.

중앙 구현 디렉토리 만들기
첫 번째 단계는 NFS를 통해 공유할 디렉토리를 만드는 것이다. NFS는 디렉토리가 구현되는 동안 애플리케이션을 저장하는데 사용될 것이다. 일단 구현되면 소스 디렉토리부터 설정 파일까지, 그리고 시스템에 필요한 기타 컴포넌트들을 저장할 때 이 디렉토리를 사용할 수 있다. 핵심은 NFS이다. 시스템이 작동하게 하려면 네트워크 상의 모든 머신에서 중앙 구현 디렉토리에 액세스할 수 있어야 한다.

상위 레벨 구조 만들기
첫 번째 단계는 네트워크에서 지원하고자 하는 각 OS을 위한 상위 레벨 구조를 만드는 것이다. 각 디렉토리는 특정 OS, 아키텍쳐, (중대한 변경일 경우) 버전 넘버의 특성에 맞춰져야 한다. 이러한 디렉토리들은 자신의 네트워크상의 머신과 맞아야 한다. 내 네트워크상에 다양한 머신들이 있기 때문에 나의 상위 레벨 디렉토리 구조는 매우 확장성이 있다. (Listing 2):
Listing 2. 내 구현 환경의 OS 레벨 디렉토리 total 58 drwxrwxrwx 2 root other 512 Jul 25 12:01 aix/ drwxrwxrwx 2 root other 512 Jul 25 13:14 darwin-ppc/ drwxrwxrwx 2 root other 512 Jul 25 13:14 darwin-x86/ drwxrwxrwx 2 root other 512 Jul 25 12:02 freebsd-x86/ drwxrwxrwx 2 root other 512 Jul 25 13:14 freedbsd-sparc/ drwxrwxrwx 3 root other 1024 Mar 9 2003 incoming/ drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-debian-x86/ drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-fedora-1-x86/ drwxrwxrwx 2 root other 512 Jul 25 12:02 linux-fedora-2-x86/ drwxrwxrwx 11 root other 512 Apr 13 16:56 linux-redhat-9.0-x86/ drwxr-xr-x 3 root root 8192 Feb 6 2002 lost+found/ drwxrwxrwx 13 root other 512 Jun 15 15:02 macosx/ drwxrwxrwx 2 root other 512 Jul 25 12:02 netbsd-x86/ drwxrwxrwx 2 root other 512 Jul 25 12:02 openbsd/ lrwxrwxrwx 1 root other 12 Jul 25 13:13 solaris -> solaris8-x86/ drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris8-sparc/ drwxrwxrwx 32 root other 1024 Jul 25 13:12 solaris8-x86/ drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris9-sparc/ drwxrwxrwx 2 root other 512 Jul 25 13:13 solaris9-x86/

너무 많다고 걱정하지 말라. 이 OS 디렉토리들은 각 OS 개정판을 위한 관련 애플리케이션 디렉토리들을 저장하는데 사용될 것이다. 애플리케이션 구현의 커스터마이징은 각 디렉토리에서 개별적으로 다루어질 것이다.

/export/build로서 반출된 구현 디렉토리를 위해 개별 파일 시스템을 사용했다. 이 파일 시스템은 충분한 공간이 있다. 구현 디렉토리의 경우, 설정, OS, 애플리케이션의 구현 버전 등에 맞추기 위해서는 충분한 공간이 필요하다. 예를 들어, 컴파일된 Perl v5.9.0은 90 MB를 차지한다. Apache는 27 MB를 차지한다.

애플리케이션 구조 만들기
각 OS 디렉토리 내에 설치하고자 하는 애플리케이션을 위한 추가 디렉토리를 만들어야 한다. 각 OS 스팩에 맞춰야 하고 실제로 필요한 애플리케이션 디렉토리만 만들어야 한다. 예를 들어, Fedora 머신에는 Perl을 설치해야 하지만 다른 머신에는 안그래도 된다. Listing 3은 레이아웃이다:

Listing 3. OS 디렉토리 내의 애플리케이션 디렉토리들 drwxrwxrwx 4 mc staff 512 May 12 12:30 apache/ drwxrwxrwx 4 root other 512 Apr 16 2003 assassin/ drwxrwxrwx 3 501 other 512 Jun 11 10:11 bind/ drwxrwxrwx 3 root other 512 Jul 24 15:37 ccache/ drwxrwxrwx 5 root other 512 Jun 21 17:12 clamav/ drwxrwxrwx 6 root other 512 Jul 25 15:28 cpan/ drwxrwxrwx 4 root other 512 Jul 25 12:35 cpanplus/ drwxrwxrwx 4 root other 512 Sep 6 2003 cyrus/ drwxrwxrwx 3 root other 512 Jun 6 16:29 dhcp/ drwxrwxrwx 3 root other 512 Apr 11 15:42 distcc/ drwxrwxrwx 3 root other 512 May 11 10:39 eggdrop/ drwxrwxrwx 3 root other 512 Apr 9 05:50 ethereal/ drwxrwxrwx 5 root other 512 Jun 8 19:12 gawk/ drwxrwxrwx 2 root other 512 May 15 08:19 gcc/ drwxrwxrwx 4 root other 512 Jul 28 2003 ircd/ drwxrwxrwx 4 root other 512 Apr 9 05:44 libpcap/ drwxrwxrwx 5 root other 512 Jul 25 13:22 mysql/ drwxrwxrwx 3 root other 512 Mar 25 13:07 nmap/ drwxrwxrwx 3 root other 512 Nov 21 2003 ogsi-lite/ drwxrwxrwx 6 root other 512 Jul 25 13:33 perl/ drwxrwxrwx 3 root other 512 Aug 19 2003 php/ drwxrwxrwx 6 root other 512 Mar 5 15:09 ppro/ drwxrwxrwx 3 root other 512 May 15 09:02 python/ drwxrwxrwx 4 root other 512 Apr 22 06:06 razor/ drwxrwxrwx 3 root other 512 Aug 24 2003 razorsdk/ drwxrwxrwx 4 root other 512 Dec 4 2003 sendmail/ drwxrwxrwx 3 root other 512 May 23 09:37 ssh/ drwxrwxrwx 4 root other 512 May 11 10:25 tcl/ drwxrwxrwx 3 root other 512 Dec 22 2003 tcpwrappers/ drwxrwxrwx 6 root other 512 Apr 24 07:13 xmltv/


이들 각 디렉토리 내부에, 애플리케이션과 구현의 구성 및 설정 방법에 따라 두 가지 구조 중 하나를 만들어야 한다. 여러분이 만드는 각 디렉토리는 활성 애플리케이션을 저장하는데 사용될 것이다. 두 가지 방법으로 구성할 수 있는데 하나는 버전 별 디렉토리 이고 다른 하나는 직접적인 애플리케이션 디렉토리이다:

버전 별 디렉토리: 애플리케이션의 각 버전 별 하나의 추가적인 디렉토리 레벨. 각 버전 별 다른 많은 구현 설정을 만들 곳에 유용하다. 예를 들어, perl-5.9.0/debug-build 또는 perl-5.9.0/std-build>를 만들 수 있다.
직접적인 애플리케이션 디렉토리: 이 디렉토리의 하위 디렉토리는 원래의 tarball에서 만들어진 디렉토리이다. 기존 OS에 대해 모든 머신들에 같은 설정을 사용한다면 작동한다.
애플리케이션의 구현과 전개 방법에 따라, 둘 중 하나 또는 두 가지 모두 사용할 수 있다. 다만 각 경우의 구조를 반드시 이해해야 한다. 전개를 시작하면서 디렉토리 레이아웃을 알아야 하기 때문이다. 예를 들어, Apache의 경우 디버깅을 위한 다른 설정을 저장하기 위해 각 버전 별 세 개 또는 네 개의 디렉토리를 가지고 있었고 개발, 스테이징, 제품 버전 별 설치 디렉토리도 갖추고 있었다. 레이아웃은 다음과 같다. (Listing 4):

Listing 4. 다른 활성 설정을 지원하는 Apache 레이아웃 ./httpd-2.0.46 ./httpd-2.0.46/staging-build ./httpd-2.0.46/devel-build ./httpd-2.0.46/prod-build ./httpd-2.0.49 ./httpd-2.0.49/staging-build ./httpd-2.0.49/devel-build


devel-build 디렉토리에는 원래 tarball의 압축을 풀 때 만들어지는 것과 같은 디렉토리를 포함하고 있다. 비교해 보면, Listing 5는 표준 구현의 모든 Perl 버전을 갖고 있는 개발 머신 상의 Perl 레이아웃을 보여주고 있다. 보다 간단해진 구조이다.

Listing 5. 직접적인 버전 애플리케이션 디렉토리 ./perl/ ./perl/perl-5.8.2 ./perl/perl-5.8.3 ./perl/perl-5.8.5 ./perl/perl-5.9.0


디렉토리를 알맞은 자리에 배치하면 각 OS와 설정에 맞춰 애플리케이션 구현을 시작할 수 있다. 애플리케이션/설정이 일단 구현되면 OS들에 이들 각각을 전개하는 것은 비교적 쉽고 단순하다.

개별 구현 설정하기
다른 애플리케이션들과 다른 설정들을 지원하는 문제들 중 하나는 설정이 어떤 애플리케이션과 상황을 위한 것인지 잊기 쉽다는 점이다. 예를 들어, Apache를 구현할 때, 대안 개발 디렉토리와 지원하고자 하는 모듈과 컴포넌트 리스트를 지정한다. 처음에는 잘되었다. 하지만 세 달 후에 다시 그 프로세스로 돌아가서 특정한 설정 부분을 기억하는 것은 거의 악몽이었다. 최신 버전으로 새로운 구현을 하기로 결정했다.

이것을 해결하기 위해, 나는 설정에 일반적으로 사용하는 라인을 저장하고 있는 한 줄의 스크립트와 함께 만든 디렉토리 구조를 사용한다. 예를 들어, 내 Apache 스테이징 서버에 다음과 같은 스크립트를 사용한다. (Listing 6)

Listing 6. Apache 스테이징 서버용 스크립트 ./configure --enable-so --enable-mods-shared=most --prefix=/export/httpd2/staging

이 라인을 스크립트에 배치하고, 적절한 이름을 정하고, 이것을 애플리케이션용 디렉토리 안에 둔다. 다시, 버전에 근거하여(설정 시스템이 변경된 애플리케이션의 경우 매우 중요함. 예를 들어, Apache 1.3.x 에서 Apache 2.x으로 변경된 경우) 또는 일반적인 애플리케이션 디렉토리에 근거하여 이를 수행한다. 예를 들어, 이 파일 이름을 apache/staging-config라고 지어 어떤 버전에서라도 사용할 수 있고 Apache 스테이징 서버를 설정하는 구현 디렉토리에서 사용할 수 있음을 설명한다.

기존 OS, 애플리케이션, 설정을 위한 설정과 구현을 실제로 수행하기 위해 다음과 같이 한다:

Listing 7. 설정과 구현 $ cd redhat-linux-9.0/apache/httpd-2.0.46/staging-build $ ../../staging-config $ make


설치 자동화
컴파일 되고 설치 준비가 된 애플리케이션 버전이 있다면 네트워크 상의 다양한 머신에 이 애플리케이션을 배포 및 설치하는 것은 쉽다. 각 머신에 개별적으로 설정/구현 프로세스를 실행할 필요가 없다. 머신이 같다면 말이다. 실행해야 할 것은 make install 뿐이다.

각 머신에 설치하고자 하는 애플리케이션 리스트를 포함하고 있는 각 OS 시스템 디렉토리에 파일을 만들어서 시스템 레벨 별로 이를 자동화한다. 어떤 경우, 다양한 설치 유형을 관리하기 위해 수 많은 다른 파일들을 만들어야 한다. 다음 파일은 애플리케이션 구현 디렉토리 리스트이다. (Listing 8):

Listing 8. OS 애플리케이션 선택 perl/perl-5.9.0 python/Python-2.3 ccache/ccache-2.3 distcc/distcc-2.13


이 파일들은 Listing 9의 스크립트로 처리된다. 보이는 그대로이다. 나열된 각 디렉토리를 실행하고 make install을 실행한다.

Listing 9. 자동 설치 스크립트 #!/bin/sh os=$1 src=$2 currentdir=`pwd` basedir=/export/build if [ -z "$os" ] then echo "No operating system definition specified" exit 1 fi if [ -z "$src" ] then echo "No application definition specified" exit 1 fi cd $basedir if [ -r "$basedir/$os/$src" ] then for dir in `cat $os/$src` do cd $basedir/$os/$dir make install done else echo "No application definition specified" exit 1 fi


머신에 특정 애플리케이션을 설치하려면 이 스크립트를 실행하고 OS 폴더와 애플리케이션 선택 파일들을 제공한다. (Listing 10):

Listing 10. 머신에 특정 애플리케이션 세트 설치하기 $ appinstall.sh solaris8-x86 standard


이 스크립트와 신중하게 만들어진 디렉토리 구조가 나머지를 수행한다.

요약
애플리케이션의 설치와 배포에 이 방법을 사용하려면 설정에 시간도 걸리고 익숙해져야 한다. 하지만 일단 실행하면 거의 모든 것이 자동이다. 사실, 어떤 애플리케이션을 설치할 수 있는지에 대한 정보와 함께 파일을 배치하기 때문에, 크론 잡 으로서 스크립트를 실행하여 네트워크 상에서 머신을 자동으로 업데이트 할 때 같은 시스템을 사용할 수 있다. 나는 일주일에 한 번 실행하지만 여러분은 한 달에 한 번만 실행해도 된다. 99%의 인스톨러의 경우 현재 버전과 설치되는 버전이 같다면 문제 없다. 모든 인스톨러가 하는 일은 이전에 사용되던 파일의 동일한 카피를 겹쳐 쓰는 것이다.

무엇보다도, 자동 메소드를 사용한다면 모든 머신을 업데이트하는 것은 애플리케이션 선택 파일을 최신 버전의 구현 디렉토리와 함께 업데이트 하는 경우이다. 최신 설치는 머신이 알아서 정해진 업데이트를 하는 동안 설치한다. 팬시 스크립트나 rsync, ssh, rsh가 필요 없다. 필요에 맞게 애플리케이션을 설정 및 커스터마이징 하고 다른 머신들이 다양한 애플리케이션 세트를 사용할 수 있도록 한다.

시작할 때 말했지만, 여러분이 해야 할 일은 약간의 훈련일 것이다. 디스크 공간이 많으면 더 좋다.


http://www-903.ibm.com/developerworks/k ··· ist.html

레드헷 리눅스의 사용자가 크게 증가하게 된 한가지 이유는 아마도 RPM이 아닌가 싶습니다. RPM(RedHat Package Manager)은 기존의 리눅스 배포판들보다 훨씬 편리해진 설치환경을 가지고 있었습니다. 기존의 리눅스 배포판들은 단순히 tar 포맷으로 묶여 있는 실행 파일을 복사하거나 소스 코드를 컴파일하는 방법을 사용해서 필요한 프로그램을 설치하거나 삭제하는 방법을 사용했습니다. 그래서 시스템에는 설치된 프로그램의 수가 많아지고, 특정한 버전의 라이브러리에 프로그램이 의존할 경우, 사용자 자신이 프로그램들을 유지하고 관리하는데 많은 문제가 있었습니다. 그리고 이미 설치되어 있던 프로그램이더라도 실수로 다시 설치하면 기존의 프로그램이 생성한 파일들이 모두 삭제되는 일이 발생할 수도 있었습니다. 또한 하나의 프로그램을 삭제하기 위해서는 그 프로그램에 관계된 프로그램과 관련 파일들을 사용자가 모두 알고 있어야만 완전히 삭제할 수 있다는 맹점을 가지고 있었습니다. 이처럼 설치하고자 하는 프로그램을 찾는 것부터 설치하는 것까지 어려움 투성이었습니다. 하지만 레드햇리눅스에서는 RPM패키지와 X윈도의 제어판을 이용해 쉽게 프로그램을 설치할 수 있습니다. RPM은 레드햇 사에서 만든 패키지 관리 도구로 리눅스 시스템을 패키지 형식으로 관리할 수 있게 해주는 관리 도구입니다. RPM은 누구나 사용할 수 있는 개방된 패키징 시스템으로 만들어져 있으며, 디스트리뷰션을 인스톨할 때는 물론, 소프트웨어를 인스톨할 때나 버전업, uninstall 할때에도 많은 도움이 됩니다. RPM의 특징은 특정한 기능을 가진 일련의 파일과 프로그램들을 묶어 쉽게 설치할 수 있게 해 줍니다. 뿐만 아니라, RPM에서는 각 패키지가 어떤 이름의 파일을 어느 디렉토리에 인스톨하였는지, 그 패키지를 이용하기 위해서는 어떤 파일이 필요한지에 대한 정보를 관리하고 있습니다. 예를 들면 다른 패키지가 이용하는 라이브러리를 가진 패키지를 언인스톨할 수 없습니다.

1. RPM 파일명 분석하기
RPM 패키지 파일에는 파일이름이 '.src.rpm '으로 끝나는 소스패키지와 '.i386.rpm'이나 '.noarch.rpm' 등으로 끝나는 바이너리 패키지로 구별할 수 있습니다. 소스 패키지는 프로그램 소스파일 등이 포함된 패키지로, 바이너리 패키지를 작성하기 위해 사용합니다. 한편, 바이너리 패키지에는 컴파일, 링크 완료 실행파일이 포함되어 있어, 이것을 인스톨하면 일일이 소스파일을 컴파일하지 않고, 소프트웨어를 실행할 수 있습니다. RPM 파일은 크게 4개의 부분으로 이루어져 있습니다. 먼저 (패키지이름), (패키지버전), (배포판에서 가지는 자체 버전), (설치될 시스템)이 RPM 앞에 붙여지게 되어 있습니다. 다음의 RPM파일명을 분석해 보도록 하겠습니다.

myth-1.2.3-4.i386.rpm

RPM 패키지 이름에서 - 는 각 필드를 구분하는 것입니다. 우선, 맨 앞부분의 myth 는 패키지의 명칭으로 가장 기본적인 것입니다. 패키지이름은 인스톨 후 조회나 언인스톨할 때 사용되는 이름입니다. 패키지 명칭에서 - 는 각 필드를 구분하려는 것으로, 이를 없애면 안됩니다. 두번째 1.2.3 은 패키지의 버전입니다. 이것은 프로그램 버전과 일치하는 것입니다. 세번째 의 4 는 패키지의 릴리즈 번호입니다. 즉 배포판에서 가지는 자체 버전으로, 이 패키지가 몇번째로 만들어진 것인지를 나타냅니다. 똑같은 프로그램으로 버전이 같다고 해도 이전에 만든 패키지를 다시 재 패키징을 하였다면, 뭔가 변화가 있고 릴리즈 번호를 올리게 됩니다. 네번째의 i386 은 어떤 시스템에서 쓰이는것인지를 나타내는 것입니다. i386 이라면 당연히 PC 계열을 나타내는 것이고 sparc 이라면 스팍 리눅스용, alpha 라면 알파 리눅스용일것입니다. (현재 레드햇은 이 세개의 시스템용으로 나옵니다.) 이 네번째 필드가 src 라고 적힌것이 있는데 그것은 소스 RPM 입니다. 바이너리 패키지를 만들기 위해 필요한것입니다. 마지막의 rpm은 소위 말하는 확장자입니다. RPM 패키지라는것을 나타내 줍니다. 버전번호와 릴리즈번호가 독립되어 있으므로, 새로운 패키지가 나왔을 때도 소프트웨어 자체가 버전업된 것인지 아니면 패키지 구성만 변한 것인지 파일명으로 알 수 있습니다. 또 버전번호나 릴리즈번호에는 숫자 이외에 문자를 포함해도 됩니다.

2. RPM 명령으로 설치하기
1. 파일 설치하기
RPM 패키지의 설치와 제거는 아주 간단합니다. 보통 다음과 같은 식을 입력하면 설치가 됩니다.

rpm -i (rpm패키지파일이름)
위와 같은 방식을 응용하여, 설치되는 모습을 확인하고자 할 때는 다음과 같은 명령어를 이용하면 됩니다.

rpm -ivh (rpm패키지파일이름)
이와 같이 입력하면, 설치 되는 모습이 화면상에 # 마크로 표시 될것입니다. 하지만, RPM 으로 패키지를 설치할 때는 사실 위의 명령보다는 -Uvh 옵션을 사용하는 습관을 익히는것이 좋습니다.

rpm -Uvh (rpm패키지파일이름)
이 명령을 사용한다면, rpm은 이 패키지의 이전 버전이 설치 되었는지를 보고, 이미 설치가 되어 있다면 업그레이드를 할 것입니다. 그냥 -i 또는 -ivh로 설치한다면 이전 버전의 같은 패키지에 대한 정보는 사라지지 않을 것이고, 또한 이전의 설정파일도 백업되지 않습니다. 따라서, 되도록 rpm - Uvh를 사용할 것을 권장합니다.
2. 설치 위치 알아보기
설치를 한 후, 파일들이 어느 디렉토리에 있는지 알아야 한다거나, 혹은 자신의 컴퓨터에 현재 어떠한 프로그램이 설치되어 있는지 알고 싶다면 다음과 같은 명령을 사용하면 됩니다.

rpm -qa | more
'-q' 옵션은 그 파일에 대한 정보를 알아내기위한 옵션이고, 'a' 옵션은 모든 파일에 대해 적용하라는 의미입니다. 이 명령을 수행하면 자신의 컴퓨터에 설치되어 있는 모든 프로그램의 목록이 페이지 단위로 나열되어 나옵니다.

3. 간략한 정보 보기
하나의 패키지에 대한 간략한 정보를 알아보려면 다음과 같이 입력하면 됩니다. 이렇게 하면, 패키지에 대한 설명이 나타납니다.

rpm -qi (rpm패키지파일이름)

4. 파일 정보 보기
텍스트가 길게 표시되는데 파일명과 버전번호, 패키징한 사람, 프로그램에 대한 설명 등이 나옵니다. 이번에는 이 프로그램의 파일에 대한 상세한 정보를 알아보기 위해 다음과 같이 입력해 봅시다.

rpm -ql (rpm패키지파일이름)
그러면 이 패키지에 포함된 파일들이 어떠한 것이 있는지 내용을 자세하게 보여줄 것입니다.

5. 프로그램 제거하기
파일에 대한 권한과 어느 디렉토리에 있는지에 대한 정보가 포함됩니다. 마지막으로 설치한 프로그램을 제거해 보겠습니다.

rpm -e (rpm패키지 이름)
위와 같이 입력하면 쉽게 제거됩니다. 물론 프로그램을 제거할 때는 패키지의 의존성에 주의해서 신중히 생각한 후 행동에 옮겨야 할 것입니다.
위에서 사용된 명령어 외의 명령어를 설명하자면 다음과 같습니다.
rpm -qf (rpm파일이름) 특정한 파일이 포함되어 있는 패키지를 확인해 볼 때
rpm -V (rpm패키지 이름) 시스템에 설치된 패키지를 검증할 때
rpm -Va 시스템에 설치된 패키지들을 모두 검증할 때 (실수로 몇 가지 파일들을 지웠는데, 어느 것을 지웠는지 확신할 수 없다. 전체 시스템을 점검해 보고 어떠한 파일이 빠져 있는지 살필수가 있다.)
rpm -Vp (rpm패키지파일이름) 시스템에 설치할 때 사용한 RPM 파일을 이용해서 해당 패키지를 검증할 때
* * 위의 과정 외에 rpm 실행모드에 관한 명령어는 다음과 같습니다
rpm --help 도움말을 출력하고자 할 때
rpm--showrc 설정사항을 출력하고자 할 때
rpm--version 버전을 출력하고자 할 때
** 그외 몇가지 부수적인 옵션이 있는데 여기서 설명하도록 하겠습니다.
이 부수적인 옵션들은 설치 또는 업그레이드 또는 제거 옵션뒤에 붙이게 됩니다. (제거 옵션에서는 --nodeps , --noscripts , --test 만을 사용합니다.)

예) rpm -e --nodeps (삭제할패키지이름)
--nodeps : 의존성을 무시하고 설치한다. 가장 많이 겪게 되는 문제로 RPM 에서는 어떠한 패키지가 깔려 있지 않으면, 그것에 영향을 받는 패키지는 설치하지 못하는 경우가 있다. 이 때 사용하는것이 --nodeps 이다.
--force : 강제로 설치 하는 것이다. 패키지 설치시 현재 패키지에 포함된 파일이 이미 다른 패키지에 의해 설치 되어 있을때, 이들이 충돌을 할 경우 에러가 발생한다. 하지만, 이 옵션으로 설치가 가능하다. 이 옵션은 이미 있는 파일은 덮어 쓰지 않는다. 이미 있는 파일마저 덮어 쓰려면 --replcaefiles를 사용하면 된다.
--oldpackage : 만약 업그레이 할 패키지가 이미 설치되어 있는 패키지보다 오래된 버전일 경우에는 업그레이드를 진행시킬 수 없다. 그래도 불가피하게 설치를 진행시켜야 할 경우, 이옵션을 이용하여 강제로 설치할 수 있다.
--percent : 패키지 파일을 설치하는것을 퍼센트로 표시해준다.
--replacepkgs : 이미 같은 패키지가 설치되 있더라도 다시 설치한다.
--replacefiles : 이미 설치된 다른 패키지의 파일을 덮어 쓰면서라도 설치한다.
--root : 디렉토리 와 디렉토리를 마치 / 처럼 생각하고 설치를 한다. 즉 "--root /tmp" 라고 한다면 /tmp 가 / 인 것으로 생각하고 그 이하로 설치하게 될것이다. 한가지 문제가 있다면 이 명령을 사용하면 RPM 정보를 기록하는 파일을 지정한 디렉토리 및 에서 찾게 된다.
--test : 패키지를 실제로 설치하지는 않고 충돌이나 의존성 문제가 있는지만을 검사한다.
--noscripts : 스크립트를 실행하지 않는다. (레드햇 패키지에는 4개의 스크립트가 들어간다. 설치 전후, 제거 전후 이렇게 4개이다.)
--excludedocs : 문서 파일은 설치 하지 않는다.

<Directory />
Options FollowSymLinks
AllowOverride None

<IfModule mod_setenvif.c>
SetEnvIF Referer "http://daum.net" pass // 도메인명을 코딩합니다. (즉, 설정한 도메인명과 현재 접속한 도메인명이 같을 경우 pass 를 반환합니다.)

<FilesMatch ".(gif|jpg|png|bmp|zip|tar|rar|alz|a00|ace|jpg|jpeg|txt|GIF|JPG|BMP|ZIP|TAR|RAR|ALZ|A00|ACE|TXT|mp3|MP3|mpeg|MPEG|wav|WAV|asf|ASF|wmv|WMV|swf|SWF|exe|EXE)$">
// 무단 링크 방지할 파일 확장자를 코딩합니다.

Order deny,allow
deny from all
allow from env=pass // pass 값이 존재할 경우 링크를 허용합니다.
</FilesMatch>
</IfModule>
</Directory>

출처 : http://www.sarangnamu.net/basic/basic_v ··· ory%3D15

출처 : http://www.sarangnamu.net/basic/basic_v ··· ory%3D15

ftp모드에서 사용할 수 있는 전용명령어는 일반 유닉스 명령어와 별도로 존재합니다.

즉, ftp로 접속했을 때 사용할 수 있는 명령어를 확인해 보려면 ftp>?을 입력해 보면 ftp명령어 리스트가 디스플레이됩니다.

또한 "ftp>? 명령어" 형식으로 해당명령어의 도움말을 볼 수 있습니다.

다음은 이들 ftp명령어중 자주 사용하는 명령어에 대한 설명입니다.

ftp명령어는 시스템에 따라 아주 조금씩의 차이는 있습니다.

ascii : 전송모드를 ASCII모드로 설정한다.(ascii또는 as)

binary : 전송모드를 BINARY모드로 설정한다.( binary또는 bi)

bell : 명령어 완료시에 벨소리를 나게한다.(bell)

bye : ftp접속을 종료하고 빠져나간다.(bye)

cd : remote시스템의 디렉토리를 변경한다.(cd 디렉토리명)

cdup : remote시스템에서 한단계 상위디렉토리로 이동한다.(cdup)

chmod : remote시스템의 파일퍼미션을 변경한다.(chmod 755 index.html)

close : ftp접속을 종료한다. (close)

delete : remote시스템의 파일을 삭제한다.(delete index.old)

dir : remote시스템의 디렉토리 내용을 디스플레이한다.(dir)

disconnect : ftp접속을 종료한다.(disconnect)

exit : ftp접속을 종료하고 빠져나간다.(exit)

get : 지정된 파일하나를 가져온다.(get index.html)

hash : 파일전송 도중에 "#"표시를 하여 전송중임을 나타낸다.(hash)

help : ftp명령어 도움말을 볼 수 있다.(help또는 help 명령어)

lcd : local시스템의 디렉토리를 변경한다.(lcd 디렉토리명)

ls : remote시스템의 디렉토리 내용을 디스플레이한다. (ls 또는 ls -l)

mdelete : 여러개의 파일을 한꺼번에 지울 때 사용한다.( mdelete *.old)

mget : 여러개의 파일을 한꺼번에 가져오려할 때 사용한다. ( mget *.gz)

mput : 한꺼번에 여러개의 파일을 remote시스템에 올린다.(mput *.html)

open : ftp접속을 시도한다.(open 168.126.72.51또는 open ftp.kornet.net)

prompt : 파일전송시에 확인과정을 거친다. on/off 토글 (prompt)

put : 하나의 파일을 remote시스템에 올린다.(put index.html)

pwd : remote시스템의 현재 작업디렉토리를 표시한다.(pwd)

quit : ftp접속을 종료하고 빠져나간다.(quit)

rstatus : remote시스템의 상황(version, 어디서, 접속ID등)을 표시한다.(rstatus)

rename : remote시스템의 파일명을 바꾼다.(remote 현재파일명 바꿀파일명)

rmdir : remote시스템의 디렉토리을 삭제한다.(rmdir 디렉토리명)

size :remote시스템에있는 파일의 크기를 byte단위로 표시한다.(size index.html)

status : 현재 연결된 ftp세션가지 모드에 대한 설정을 보여준다.(status)

type : 전송모드를 설정한다.(type 또는 type ascii 또는 type binary)

[출처] 리눅스@Work 2001. 12월호 기사
http://tt.co.kr/~antihong/

메일서버운영과 관련한 에러대처방법에 대한 문서입니다.

================================================

메일서버의 장애와 대처 방법 

인터넷이 웹중심으로 발전하면서도 의사 소통 수단이나 마케팅 수단으로 여전
히 중요도가 높아지고 있는 것이 바로 메일 서비스이다.  이번 호에서는 
sendmail 과 imap 을 이용한 pop3d 서비스 제공시 발생 가능한 각종 메일 서비
스의 장애에 대비하여 안정적인 메일 서비스를 제공하기 위한 방안에 대해 알
아보도록 한다.

오늘과내일 넷센터 홍석범(antihong at tt.co.kr)


보내고 받는 메일의 양 제한하기

지난 11월호에서도 잠깐 언급한 것처럼 시스템의 제한 설정과  서비스의 안정
성은 매우 깊은 연관성을 가지고 있다. 기본적으로 대부분의 서비스는 유저가 
사용 가능한 시스템의 자원 제한이 거의 설정되어 있지 않은데, 메일 서비스
도 마찬가지이다. 
최근에는 메일의 이용율이 높아지고, 메일의 컨텐츠도 전통적인 텍스트 방식에
서 음성,이
미지등 각종 동영상이 주종을 이루면서 용량도 점점 커지고 있다. 물론 그만
큼 하드웨어나
메일 서버의 소프트웨어적인 성능도 향상되고 있지만  용량이 큰 메일을 주고 
받는다면 
당연히 시스템의 부하가 올라가기 마련이고 이로 인하여 같은 서버내 다른 서
비스에까지 
영향을 미치게 된다.  따라서 시스탬에서 보내는 메일 서비스(SMTP)나 받는 메
일 서비
스(POP3)를 제공하고 있다면 용량이 큰 파일을 주고 받는 것을 적절히 제한할 
필요가 있다.

sendmail 은 로컬의 메일을 외부로 발송하는 SMTP(보내는 메일서버) 기능도 있
지만 외부에서 서버내 계정으로 전송되는 메일을 받아서 서버에 저장하는 기능
도 있다. 이때 기본적으로는 보내거나 받는 메일의 양에 대한 제한이 전혀 없
어 10메가 이상이 넘는 큰 사이즈의 메일이 송 수신 될 경우 서버에 과부하가 
걸릴 수 있으므로 아래와 같이 각각의 설정(보내는 메일과 받는 메일의 양) 
을 적절히 제한하여 설정하는 것이 좋다.

>> SMTP 서버에서 보내는 양 제한하는 법. 

/etc/mail/sendmail.cf (또는 /etc/sendmail.cf. 이는 sendmail 의 패키징 방
법에 따라 다르다.) 파일에서 다음과 같이 MaxMessageSize 부분의 주석을 제거
하고 제한하고자 하는 적절한 값을 입력한다. 

# maximum message size 
O MaxMessageSize=5024000 

위와 같이 설정하였을 경우 현재의 서버를 보내는 메일 서버로 이용시 첨부 파
일이 5M 이상 초과하거나 웹에서 /usr/sbin/sendmail 을 실행하여 외부로 메일
을 발송하는 메일링 리스트등의 프로그램에서도 메일 발송시 5 메가 이상의 메
일은 보낼 수 없게 된다.
5024000 은 byte 단위이며 설정 변경 후 변경된 내용을 적용하려면 killall –
HUP sendmail 로 sendmail 데몬을 Refresh 하면 된다.

>> 받는 메일 서버에서 받는 양 제한하는 법. 

외부에서 서버로 들어오는 메일에 대해서 용량을 제한하고 싶다면 같은 파일
(sendmail.cf) 에서 "Local and Program Mailer specification" 부분을 설정
해 주면 된다. 

Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30, 
R=20/40, M=5024000, T=DNS/RFC822/X-Unix, A=procmail -Y -a $h -d $u 

위와 같이 T=DNS/RFC822/X-Unix  앞부분에 M=5024000 부분을 추가해 주면 된
다.
마찬가지로 5024000는 byte 단위이며 각자의 시스템 환경에 따라 원하는 용량
만큼 적절히 설정해 주면 된다   역시 설정 변경 후 sendmail 을 refresh 하
면 적용이 된다. 
위의 경우 서버에서는 5메가 이상의 메일은 수신하지 않으며 5메가 이상의 메
일을 
보낸 이는 

552 5.2.3 <antihong at tt.co.kr>... Message is too
large; 5024000 bytes max 
554 5.0.0 <antihong at tt.co.kr>... Service
unavailable 
와 같은 에러 메시지를 회신받게 된다.  

아울러 
# maximum number of recipients per SMTP envelope
O MaxRecipientsPerMessage=20

와 같은 부분이 있는데, 이 부분은 한번에 메일 발송 시 동시 발송(참조 발송)
이 가능한 메일 계정의 수를 뜻하는 것으로 SMTP 서비스를 제공한다면 이 설정
을 적용하는 것이 좋다. 기본적으로 이 값에도 제한이 없으므로 먼저 주석을 
삭제한 후 적절한 값을 설정해 주면 한번에 동시 발송 가능한 메일의 수도 제
한할 수 있다.
(위의 경우에는 한번에 참조 발송이 가능한 메일 유저를 20명으로 제한) 
설정이 끝난 후에는 killall –HUP sendmail 로 sendmail 을 재가동해주면 적
용된다.

 

메일 용량 쿼터 설정하기 

각 유저의 홈페이지 공간에 대한 쿼터 설정방법은 잘 알고 있는데, Sendmail 
을 제공시 메일 용량 쿼터에 대한 설정은 잘 모르는 경우가 많이 있다. 매일 
쿼터에 대한 설정은 다소 복잡하기는 하지만 설정은 가능하다.  기본적으로 
각 유저의 메일은 /var/spool/mail/ 디렉토리에 자신의 계정 소유로 저장이 되
게 되는데 바로 이 특성을 이용하여 쿼터 설정이을 하면 된다.   쿼터는 각 파
일 시스템별로 각각 설정이 가능하므로 각 유저의 홈디렉토리외에 /var 파티션
에도 추가적으로 쿼터를 설정하면 되는 것이다.
쿼터를 설정하는 방법은 일반적인 방법과 동일하다. 
먼저 /etc/fstab 파일을  열어 /var 파티션이 별도로 설정되어 있다면 /var 파
티션에,  별도로 없으면 / 파티션에 유저쿼터나 또는 그룹쿼터 설정을 하면 된
다. 

/dev/sda1             /home       ext2    defaults,usrquota=/home/.quota 
/dev/sda8             /var         ext2    
defaults,usrquota=/var/.mailquota 
 
위에서는 /home 파티션에도 쿼터 설정을 하고 /var 파티션에도 쿼터 설정을 
한 것을 볼 수 있다.  이후 touch /home/.quota 및 touch /var/.mailquota 로 
사이즈가 0인 파일을 생성한 후  quotacheck –a 를 실행하면 파일 시스템을 
스캔하여  디스크 사용량을 체크하여 해당 파일에 정보를 저장한다. 

edquota user 를 실행하면 

/dev/sda1: blocks in use: 0, limits (soft = 99980, hard = 99980)
        inodes in use: 0, limits (soft = 0, hard = 0)
/dev/sda8: blocks in use: 0, limits (soft = 29980, hard = 29980)
        inodes in use: 0, limits (soft = 0, hard = 0)

위와 같이 쿼터 설정이 나오는데,  여기에서 /dev/sda1 은 /home/ 디렉토리에 
대한 쿼터 설정이고, /dev/sda8 은 /var/ 디렉토리에 대한 쿼터 설정이다. 위 
설정으로 각각 /home 디렉토리에는 100메가로, 메일 용량은 30메가로 총 130메
가를 할당하여 쿼터를 설정한 것을 알 수 있다. 만약 별도의 /var 파티션이 없
이 / 파티션만 있는 상황에서 100 메가로 쿼터 설정을 했다면 이 용량은 홈페
이지의 용량과 메일 용량을 합쳐서 100메가로 적용이 되므로 주의하기 바란다.

##################### 참고.  Quota 의 설정에 대해 
위와 같이 edquota 사용시 관련된 라인이 아래와 같이 보이는 부분이 있다. 
이 중 
 "blocks in use:" 는 유저가 현재 파티션에서 사용중인 총 블럭의 수를 킬로
바이트로, 
 "inodes in use:" 는 유저가 현재 파티션에서 사용중인 총 파일의 개수를 보
여준다.
 이 두개의 "blocks in use:" 와 "inodes in use:" 는 시스템에 의해 자동으
로 설정되고
 제어되므로 이 값을 임의로 변경할 필요는 없다. 
그리고 quota 설정시 soft 제한(soft = 5000)은 유저가 사용할 수 있는 최대 
용량을 뜻하며  (이 예제에서는 약 5M 이다.) hard 제한(hard = 6000)은 유저
가 초과할 수 없는  절대적인 디스크 사용량을 뜻한다.  "hard limit" 
는 "grace period" 옵션이 설정되었을 때에만 적용된다.
grace period 는 쿼터가 설정된 유저나 그룹이 soft limit 을 초과한 이후에
도 사용 가능한 시간의 한계이다. 예를 들어서 여러분이 관리하는 시스템
에 "해당 유저의 홈디렉토리를 50MB 로 쿼터 제한하고  초과시 7일간의 유예기
간을 준다"는 정책을 세울 수도 있다. 각자 유예 기간의 설정에 대해서는 나름
대로 적당하다고 생각하는 기간을 정의할 수 있다. grace period 는 
edquota –t 로  확인 및 설정할 수 있으며 아래의 경우에는 grace period 가 
7일로 설정되어 있는 것을 알 수 있다.

/dev/sd1: block grace period: 7 days, file grace period: 7 days
/dev/sda8: block grace period: 7 days, file grace period: 7 days

그리고 한 유저에게 적용된 쿼터 설정을 다른 유저에게도 그대로 적용하려
면 –p 옵션을 사용하면 되는데, 아래와 같이 실행하면 edquota 프로그램
은 /etc/passwd 에 정의된 유저중 UID 가 499 이후의 모든 유저에 대
해 "user" 의 쿼터 설정을 그대로 복사하게 된다.

edquota -p user `awk -F: '$3 > 499 {print $1}' /etc/passwd`

####################################################################


만약 쿼터가 초과된 계정에 메일을 발송하게 되면 아래와 같은 에러 메시지가 
나며 더 이상 메일을 수신하지 못하게 된다. 




 


 sendmail 이 정상적으로 작동하는지 여부를 아는 방법

sendmail 이  현재 작동중인지 확인하는 방법은 아래 두 가지 방법으로 가능하
다.

(1)	# ps auxw|grep sendmail 로 확인
위와 같이 확인시  
root      0.0  0.0  2684 1460         S    Aug24 sendmail: accepting 
connections on port 25

와 같이 sendmail: accepting connections on port 25 로 보이면 정상적으로 
작동하는 것이다. 만약 sendmail 이 다운되어 작동하지 않을 때는 sendmail: 
rejecting connections 라는 메시지가 보이게 된다. 

(2)	sendmail 이 반응하는 25번 포트로 접속.

# telnet tt.co.kr 25
Trying 211.47.66.50...
Connected to tt.co.kr.
Escape character is '^]'.
220 www10.tt.co.kr ESMTP Today and Tomorrow (http://tt.co.kr/)

와 같이 sendmail 이 바인딩하는 25번 포트로 telnet 을 접속하면 sendmail 
이 반응을 하게 되는데, 위와 같이 접속을 하여 응답이 있을 경우에는 접속을 
받아들일 준비가 되어 있는 상태이며 반응하지 않을 때는 
Trying  tt.co.kr...
telnet: Unable to connect to remote host: Connection refused
와 같이 접근이 거부되었다는 것을 알 수 있다.


갑자기 sendmail 이 작동하지 않을 때 

 sendmail 이 작동하지 않는 경우는 주로 2가지이다.

첫번째는, 시스템의 부하율인 Load Average 가 높아져 sendmail 이 작동하지 
않는 경우이고 두번째는 sendmail 에서 받는 메일이 저장되는 /var 파티션이 
100%가 되었을 경우이다. 
Sendmail 은 기본적으로 시스템의 Load Average 수치가 12를 초과하였을 경우
에는 자동으로 작동하지 않게 되는데 이는 sendmail이 서비스 거부 공격등으
로 시스템의 부하가 높아졌을 때 sendmail 로 인하여 시스템이 다운되는 것을 
막기 위한 조처이다.
이 값을 수정하려면 sendmail.cf의 
# load average at which we refuse connections
O RefuseLA=12 
에서 수정한 후 killall –HUP sendmail 로 재실행해 주면 되고, 이 값은 각각
의 시스템에 따라 적절히 조정하면 된다.  만약 현 시스템의 특성상 늘 부하
가 높아 로드가 자주 12를 초과한다면 이 값을 각자의 시스템 환경에 맞게 적
절히 조절하여야 외부에서 오는 메일을 받을 수 있게 된다.(서버에서 25번 포
트로 바인딩하고 있어야 외부에서 오는 메일을 수신할 수 있다.) 그리고 메일
이 저장되는 /var/spool/mail 파티션이 가득 찼을 경우(파티션 100%) 에도 
sendmail 이 작동하지 않으므로 파티션이 가득 찼을 경우에는 /var/log/ 등에
서 불필요한 데이터를 삭제하여 /var/spool/mail 이 포함된 파티션이 100% 를 
넘지 않도록 하여야 한다. 용량 정리를 하여 파티션이 100%가 넘지 않으면 
sendmail 이 자동으로 살아나는 것을 알 수 있다.
또한 시스템의 Load Average 가 8을 넘으면 서버를 통해 메일을 발송해도 메일
을 통해 바로 전송되지 않고 일단 서버의 메일 큐에 저장이 된 후에 발송이 되
게 된다. 이 역시 같은 이유 때문인데 이 수치는 sendmail.cf 의 

# load average at which we just queue messages
O QueueLA=8
에서 적절히 설정하면 된다. 

참고로 현재 시스템의 Load Average는 w 명령어를 이용하여 확인 가능하다. 
w 를 이용시 시스템의 Load Average 는 0.25, 0.40, 0.43  와 같이 보이는데 
이는 각각 현재를 기준으로 지난 1분, 5분, 15분간의 평균 시스템 부하율을 나
타낸다. 
 


 sendmail 애서 보내는 메일(SMTP) 기능을 차단하고자 할 때 

sendmail 에서 Relay 기능을 막아 두었다 하더라도 최근 버전에는 사용자 인증
(SMTP AUTH) 기능이 있어 서버에 계정이 있으면 모든 유저가 메일 서버를 이용
해 SMTP 기능을 이용하여 메일을 발송할 수 있다. 이를 막으려면 최신의 
8.11.4 나 8.11.5 와 같이 최신 버전으로 업그레이드 후 /etc/mail/smtpauth 
파일에 보내는 메일  기능을 허용할 유저를 입력해 주면 된다. (최근에 
8.11.6 이전 버전에 심각한 보안 문제가 확인되었으므로 반드시 8.11.6 버전이
나 8.12 버전으로 업그레이드하여야 한다.)  파일을 생성 후 아무런 유저도 입
력하지 않으면 서버에 계정이 있다 하더라도 어느 누구도 메일을 발송할 수 없
게 된다. 따라서 최신의 8.11.6 버전으로 업그레이드 할 것을 권장한다. 이외 
여러 변형된 방법이 존재하는데, ipchains 나 iptables 를 이용해 패킷 필터링
을 하는 방법도 있다.

커널 2.2.X 일 경우
ipchains -A output -p tcp -y -d 0/0 25 -j DENY
커널 2.4.X 일 경우 
 iptables -A OUTPUT -p tcp --syn --dport 25 -j DROP 

위와 같이 설정시 목적지(Target) 포트가 25번 포트로 향하는 초기화(SYN) 패
킷만을 차단하여 메일을 발송할 수 없도록 한다. 물론 초기화(SYN) 패킷에 대
해서만 필터링을 하였으므로 외부에서 오는 메일을 받는 것은 관계 없다. 

바이러스 메일 필터링 방법

최근에 Sircam 이나 Nimda 등 일정 주기마다 발생하는 바이러스 메일 때문에 
서버 관리자들은 마음 고생이 이만저만이 아니다. Sendmail 에서는 이러한 바
이러스 메일이나 스팸메일에 대해 룰셋(ruleset)을 이용하여 차단하는 기능이 
있는데, 이를 사용하는 방법에 대해 알아보도록 하자.
Sendmail 에서는 제목이나 메일러 또는 첨부파일의 화일명등 각종 메일헤더 정
보를 이용하여 필터링을 할 수 있는데, 먼저 발송되는 메일 제목(subject)으
로 필터링을 해 보도록 하자. 아래는 메일 제목에 ILOVEYOU 로 발송하는 멜리
사 바이러스를 차단하는 룰셋을 적용해 본 예이다.

먼저 sendmail.cf 파일을 열어 제일 하단에 아래의 내용을 추가한다.

HSubject: $>Check_Subject
D{WORMmsg}Access Denied - This message may contain a virus.

SCheck_Subject
RILOVEYOU               $#error $: 501 ${WORMmsg}
RRe: ILOVEYOU           $#error $: 501 ${WORMmsg}
RFW: ILOVEYOU           $#error $: 501 ${WORMmsg}

# 주의 :  $#error 앞의 blank는 스페이스가 아니라 반드시 탭으로 띄워주어
야 한다.
Sendmail.cf 의 설정 내용이 다소 어렵고 복잡하기는 한데, 위 설정의 의미를 
간단히 
살펴보도록 하자.
 
H -- 위 경우에는 헤더에서 Subject:라는 문자열을 찾아 이 헤더를 
Check_Subject로 정의한다. 
D -- WORMmsg 라는 매크로를 정의하여 해당 룰셋에 적용되는 제목을 확인시 발
송한 
    유저에게 보낼 메시지를 정의한다.
S -- 헤더에서 check_subject로 정의한 부분을 룰셋으로 지정하는 부분이다.
R -- 해당 문자열이 포함된 메일을 발견시 앞에서 정의한 에러 메세지를 첨부
하여 
     반송을 시킨다.

위와 같이 룰셋을 적용하였을 경우 "I LOVE YOU" 와 같이 공란이 있을 경우 적
용되지 않으며 "ILOVEYOU from me" 와 같이 특정 단어가 추가시에도 적용되지 
않으며 반드시 
정확히 일치하여야 한다. 추가적으로 회신시 추가되는 Re: 와 전달(포워딩)시 
추가되는 FW: 가 추가된 메일도 거부한다.
 
다음으로 얼마전 유행했던 Sircam 바이러스 메일을 필터링해 보도록 하자.
Sircam 바이러스의 헤더를 보면 정상적인 메일과는 달리 메일 헤더에 
Content-Disposition: Multipart message 와 같은 부분이 추가되어 있으며 이 
특징을 이용하여 필터링을 하면 된다.

Sendmail.cf 파일에 아래의 룰셋을 추가하면 된다.

HContent-Disposition: $>check_sircam
D{SIRCAM}"Warning: I  Guess Sircam.worm Virus"
Scheck_sircam
RMultipart message      $#error $: 550 ${SIRCAM}

# 주의 :  $#error 앞의 blank는 스페이스가 아니라 탭으로 띄워주어야 한다.

sendmail.cf의 수정을 끝낸 후 바로 sendmail을 재 시작하지 말고
룰셋이 정상적으로 작동하고 있는지 아래와 같이 테스트를 하는 것이 좋다.

 # /usr/lib/sendmail –bt                 # 테스트 모드로 접속
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> check_sircam Multipart message        # Sircam 룰셋 테스트 
check_sircam       input: Multipart message
check_sircam     returns: $# error $: 550 553 Warning: I  Guess 
Sircam.worm Virus
> ctrl-D                                # 테스트 종료 

위와 같이 확인된 후 sendmail을 재시작(killall –HUP sendmail) 하면 바로 
적용된다.
아래와 같이 tail –f  /var/log/maillog 로 로그 파일을 지켜보면 아래와 같
이 실제로 Sircam 바이러스가  필터링되고 있음을 확인할 수 있다. 

Sep  27 15:09:51 www sendmail[21386]: f8369of21386: 
to=<antihong at tt.co.kr>, delay=00:00:01,
pri=241584 Warning: I  Guess 
Sircam.worm Virus.

마지막으로 최근에 가장 영향을 많이 주었던 변형된 Nimda Worm 을 필터링하
는 방법에 대해 알아보자. Nimda Worm 은 정상적인 메일 메시지와 달리 헤더에
boundary="====_ABC1234567890DEF_===="       나 
boundary="====_ABC123456j7890DEF_===="      라는 부분이 있는데, 이 부분으
로 필터링을 할 수 있다. 즉 메일 헤더에 위와 같은 설정이 되어 있으면  
Nimda Worm 으로 간주하고 필터링 하면 되는 것이다. Sircam 에서와 같은 방법
으로 sendmail.cf 파일의 설정은 아래와 같다.

HContent-Type: $>check_ct

D{NIMDA}"I guess NIMDA.WORM!!!"

Scheck_ct
R$+boundary="====_ABC1234567890DEF_===="       $#error $: 550 ${NIMDA}
R$+boundary="====_ABC123456j7890DEF_===="       $#error $: 550 ${NIMDA}

이외 메일 필터링에 대한 더욱 구체적인 방법에 대해서는  
http://certcc.or.kr/paper/tr2001/tr2001-03/email security by 
procmail.html 나 
http://quanta.khu.ac.kr/~dacapo/sendmail/rulesets/ 를 참고하기 바란다.
그리고 이외 관련하여 바이러스를 스캔하거나 필터링 할 수 있는 몇몇 프로그
램이 있는데 이에 대해서는 http://www.rav.ro/ , http://www.amavis.org/ , 
http://www.sophos.com/ 등을 참고하기 바란다.


메일이 받아지지 않는 경우 

아웃룩 익스프레스에서 “배달” 을 눌러 메일을 수신하려고 할 때 메일이 받
아지지 않는  경우가 있다. 이러한 경우에는 아래와 같이 여러가지 이유가 있
을 수 있으니 아래의 사항에 대해 하나씩 원인을 찾아보기 바란다.
(1)	IMAP 패키지가 설치되지 않았을 경우 
서버에 배달되어 있는 자신의 계정으로 온 메일을 클라이언트 PC에서 받으려
면 pop3 데몬이 반응하게 된다.  pop3d 는 IMAP 패키지안에 포함되어 있으므
로, IMAP 패키지를 설치하여야 pop3 를 사용할 수 있다. Rpm 으로 설치했다면 
rpm –q imap 으로 현재 시스템에 imap 패키지가 설치되어 있는지 확인한다. 
또는 /usr/sbin/ipop3d 파일이 있는지 확인해 본다.
(2)	Inetd 에 설정되어 있지 않을 경우 
pop3d 는 inetd 또는 Xinetd 에서 작동하게 된다. 
/etc/inetd.conf 또는 /etc/xinetd.conf 파일을 살펴보아 ipop3 가 주석처리 
되어 있거나 pop3 가 disable =  yes 로 되어 있지는 않은지 확인한다.
(3)	TCP Wrapper 에 설정되었는지 여부 확인
/etc./hosts.deny 에 pop3d 접근이 차단되지는 않았는지 확인한다.
(4)	계정에 Lock 이 걸리지 않았는지 확인
메일을 받는 과정에서 갑자기 회선이 끊기거나 PC가 다운되는 등 비정상적으
로 종료시 서버의 pop3d 프로세스가 죽지 않고 계속 남아 있는 경우가 있다.
이러한 경우 계정에 “Lock 이 걸렸다” 라고 하며 이러한 경우에는 해당 프로
세스를 찾아 kill 을 하면 된다. 만약 계정에 Lock 이 걸린 상태에서 아웃룩 
익스프레스에서 메일을 수신하려고 하면 아래와 같은 에러가 나게 된다. 
“메일 서버에 로그온하는 데 문제가 있습니다. 지정한 암호가 거부되었습니
다. 
계정: 'temazone.com', 서버: 'tt.co.kr', 프로토콜: POP3, 서버 응답: 
'-ERR Can't get lock.  Mailbox in use', 포트: 110, 보안(SSL): 아니오, 
서버 오류: 0x800CCC90, 오류 번호: 0x800CCC92”

(5)	Pop3 접속이 많은 경우 
Pop3d 가 서비스되는 inetd는 기본적으로 60초동안 40회의 접속을 받아들이
도록 (즉, maximum 40회 fork되도록) 설정되어 있다. 따라서 짧은 시간에 
pop3d 
요구가 많을 경우에는 메일로그에 pop3/tcp server failing (looping) 라는 메
시지가 
나면서 pop3d 데몬 자체가 다운되어 버리므로 동시에 처리 가능한 프로세스의 
한계
를 적절히 높여주어야 한다.
이를 위해서는 /etc/inetd.conf 를 열어 아래와 같이 수정하면 된다. 

이전설정) 
pop-3    stream    tcp    nowait    root     /usr/sbin/tcpd    ipop3d 

변경 설정)
pop-3    stream    tcp    nowait.200    root    /usr/sbin/tcpd     
ipop3d 
(위의 경우 처리 가능한 프로세스를 200회로 늘려주었다.)
이후 killall -HUP inetd 를 하면 된다. 

(6)	110 번 포트로 확인
아래와 같이 pop3d 포트인 110번 포트로 직접 접속하여 수작업으로 확인 가능
하다. 

# telnet  pop3.tt.co.kr 110           # 110번으로 직접 확인
Trying 210.17.6.5...
Connected to pop3.tt.co.kr.
Escape character is '^]'.
+OK POP3 pop3.tt.co.kr v2001.76 server ready
user abc                              # abc 라는 계정으로 접속
+OK User name accepted, password please
pass xyz                              # abc 의 암호 xyz 입력
+OK Mailbox open, 10 messages
quit                                  # 접속을 끊음.
+OK Sayonara
Connection closed by foreign host.

위의 경우는 정상적인 경우이며 에러가 있을 경우(만약 암호가 다르게 설정되
었을 경우 -ERR Bad login 와 같은 메시지가 나게 된다.) 각각의 경우에 따라 
에러 메시지를 
각각 확인할 수 있다. 

(7)	mail –v 로 확인
타 서버에서 mail –v antihong at tt.co.kr 와 같이
메일을 발송하여 정상적으
로 메일이 도착하는지를 확인해 본다. –v 옵션을 이용하여 메일 발송시에는 
메일 전송의 경로 및 메일 서버간에 주고받는 메시지를 확인할 수 있으므로 문
제의 원인을 찾는데 도움이 된다.



특정한 곳으로만 메일이 돌아올 때 

다른 곳은 문제가 없는데, 해외등 특정한 곳으로만 메일이 전송되지 않고 리턴
되는 경우가 있다. 이러한 경우라면 자신의 메일서버가 mail-abuse.org 의 블
랙 리스트에 등록되어 있지는 않은지 확인해 볼 필요가 있다. 특히 회신된 메
일에 “...refused by blackhole site relays.mail-abuse.org” 와 같은 메시
지가 보인다면 반드시 여부를 확인해 보아야 한다. 적지 않은 메일 서버에서
는 메일 수신시 실시간으로 이 데이터를 참조하므로 mail-abuse.org 에서 스
팸 메일 서버로 등록되면 이 기관에 등록된 도메인으로 메일을 보낼 때 받는 
쪽에서는 스팸 메일로 간주하고 수신을 거부하게 된다. 이를 확인하는 방법은 
http://mail-abuse.org/cgi-bin/nph-rss 사이트에서
메일 서버의 IP 를 조회
해 보면 된다.  아래는 위 사이트에서 한 IP 에 대해 조회해 본 결과 블랙 리
스트에 등록되어 있는 것을 보여주고 있다. 이러한 경우라면 조회한 메일 서버
의 Relay 가 허용되어 스팸 메일 서버로 사용된 적이 있거나 현재 사용되고 있
다는 뜻이다.  만약 스팸메일 서버로 등록되어 있지 않다면 211.47.65.xxx is 
NOT currently on the RSS list 와 같이 보이게 된다.  
 
 


 

자신의 메일 서버를 이 블랙리스트에서 제외하려면 먼저 자신의 메일서버에 
Relay 가 허용되어 있는지 확인 후 메일 서버에서 Relay 를 거부 설정한 후  
If you'd like 211.47.65.135 to be removed from our list, please click 
here. 를 따라 클릭하여 신청을 하면 된다. 이 링크를 클릭하면 신청폼이 나오
는데, 이 곳에 입력하여 신청을 하면 바로 처리가 된다. Relay 거부 설정을 
한 후 신청을 해야 처리가 되므로 반드시 사전에 Relay 거부 설정을 확인하기 
바란다. 메일 서버의 Relay 여부를 조회하는 방법에 대해서는 본지 10월호 
“철벽 보안을 위한 모니터링 올가이드” 를 참고하기 바란다.


복수 MX 설정시 주의해야 할 점  

DNS 서버에서 설정하는 MX 레코드는 해당 호스트로 수신되는 편지를 다른 호스
트로 라우팅 하도록 한다. 특히 웹서버와 메일 서버를 분리하고자 할 경우 사
용되는데, 원격 호스트에서 아래와 같이 설정된 도메인 tt.co.kr 로 편지를 송
신할 경우에 Sendmail이 어떻게 동작하는지 알아보자. 


tt.co.kr.         IN   MX    10     mail1.tt.co.kr. 
                IN   MX     20    mail2.tt.co.kr. 
                IN   MX     20    mail3.tt.co.kr. 

다음은 메일이 수신되는 차례를 보여준다.

(1) Preference 값이 10으로 가장 낮은 mail1 로 먼저 배달을 시도한다. 
(2) 만약 mail1.tt.co.kr 이 접근이 불가능하면 mail2 혹은 mail3 으로 배달
을 시도한다. 
(3) (2) 에서 시도한 메일서버로도 접근이 되지 않으면 (2)에서 접근 되지 않
은 호스트로
   배달을 시도한다. 즉 mail2 로 전송을 시도했다면 mail3 으로 배달을 시도
한다.
(4) mail2 와 mail3 서버에 접근이 불가능하다면 자체 큐잉 후, 일정 기간동
안 주기적으로       
    1-3의 과정을 반복한다. 

흔히 MX 레코드에 대해 잘못 생각하는 것 중 하나는 만약  mail1 이 다운되어 
mail2 로 편지가 배달되었을 때, 편지가 mail2 의 메일 박스에 저장 된다고 생
각하는 것이다. 만약  이렇게 된다면 유저 입장에서는 메일 수신시 pop3 서버
를 mail1.tt.co.kr 와 mail2.tt.co.kr 과 같이 여러 개 설정해야 하는 것처럼 
보인다. 그러나 일반적으로 mail2.tt.co.kr 이나 mail3.tt.co.kr 처럼 
Preference 가 높은(즉 우선도가 낮은) 값을 갖는 메일 서버는 큐잉 서버로 동
작하도록 설정하기 때문에, 결국 메일은 하나의 호스트(mail1)로 모이게 되는 
것이다. 위와 같이 mail2와 mail3 서버가 큐잉 메일 서버로 작동하려면 mail1 
와 mail2의 sendmail 이 아래와 같이 설정되어야 한다. 

(1) 해당 도메인(tt.co.kr)에 대한 인증을 갖지 않아야 한다. 
(즉, mail2 나 mail3 메일 서버의 sendmail.cw 또는 local-host-names 파일에 
tt.co.kr 이 설정되어 있으면 안 된다.) 

(2 )서버는 해당 호스트로의 메일 릴레이(Relay)를 허용하여야 한다. 
(즉, /etc/mail/access 에서 아래와 같이 정의되어야 한다.) 
mail1.tt.co.kr    relay 

인증을 갖지 않아야 한다는 것은 Sendmail의 w 클래스(sendmail.cw(local-
host-names)  혹은 sendmail.cf의 Cw)에 tt.co.kr 도메인이 설정되지 않아야 
하는 것을 의미하고, 메일 릴레이란 수신되는 편지의 최종 배달지가 자신이 아
닐 경우, 즉 인증을 갖지 않을 경우 편지를 해당 호스트로 포워딩하는 것을 의
미한다.  최근의 배포판에서는 기본적으로 sendmail이 릴레이를 거부하도록 설
정되어 있으므로 메일 큐잉 서버의 경우는 해당 호스트를 목적지로 하는 메일
에 대해서는 릴레이를 허용하도록 설정하여야 한다는 것을 주의하기 바란다. 
mail1 의 다운으로 인해 mail2 로 전달되는 메일은 메일큐에 저장되어 있으면
서, 일정 기간(Sendmail.cf에서 지정된 Timeout.queuereturn=5d 만큼)동안 주
기적(Sendmail 구동시 지정된, 일반적으로 30분 -q30m)으로 mail1 로 배달이 
재시도된다. 


메일 서버의 버전을 숨기는 법

다른 데몬도 마찬가지이지만 메일 서버 역시 해당 포트로 원격 접속을 해  보
면 메일 서버의 버전 정보등을 확인할 수  있다. 그러나 시스템 관리자 입장에
서 보안상의 문제로 현재 운영중인 메일 서버의 버전등을 숨기거나 속이고 싶
을 때가 있는데. 이러한 경우에는 아래의 방법을 이용하면 된다.

(1) sendmail 의 경우 
   sendmail.cf 파일을 보면 아래와 같은 설정이 있다.
# SMTP initial login message (old $e macro)
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
이 부분을 적절히 삭제하거나 다른 정보로 입력후 sendmail 을 재가동하면 된
다.
필자가 운영하는 메일서버의 경우 
O SmtpGreetingMessage=$j Today and Tomorrow(http://tt.co.kr/) 와 같이
설
정하였고 이때 25번 포트로 접속시 보이는 정보는 아래와 같다.

# telnet tt.co.kr 25
Trying 211.47.66.50...
Connected to tt.co.kr.
Escape character is '^]'.
220 www10.tt.co.kr ESMTP Today and Tomorrow(http://tt.co.kr/)

(2) pop3d 의 경우 
pop3d 의 경우 소스에서 직접 수정하여야 하는데, 압축 해제한 디렉토리
의 /src/ipopd 에 보면 ipop3d.c 파일이 있다. 이 파일을 살펴보면  

char *version = "2001.75";   /* server version */
라는 부분이 있는데,  필자가 운영하는 pop3d 의 경우 소스에서 
char *version = "xxxxxxxxxx";   /* server version */
와 같이 수정 후 컴파일 하였고 이때 110번 포트로 원격 접속시 보이는 정보
는 아래와 같다.

# telnet tt.co.kr 110
Trying 211.47.66.50...
Connected to tt.co.kr.
Escape character is '^]'.
+OK POP3 www10.tt.co.kr vxxxxxxxxxx server ready

버전외 다른 각종 정보도 수정할 수 있으니 각자 상황에 맞게 적절히 설정하
기 바란다.


sendmail 과 관련된 몇 가지 명령어

>> mail1q 
mailq 프로그램의 목적은 큐잉된(/var/spool/mqueue 에 저장된) mail 메시지
의 요약된 정보를 보여준다.  네트워크 다운등 어떤 특정한 이유로 바로 발송
되지 못한 메일은 일차적으로 /var/spool/mqueue 에 큐잉된 상태로 저장된 후 
일정 시간마다 발송을 위해 재시도가 되는데,  현재 큐잉된 메일 메시지의 요
약 정보를 보려면 아래와 같이 확인할 수 있다.

# mailq

/var/spool/mqueue/q1 (2 requests)
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------
------
f7A84oV15068     1446 Fri Aug 10 17:04 nobody
                 (Deferred: Connection timed out with kebi.net.)
                                       darling at kebi.net
f775ieF24893   521898 Tue Aug  7 14:44 <shlee at
tt.co.kr>
                 (Deferred: Connection timed out with mail.unitel.net.)
                                       <cf1318 at
unitel.net>
/var/spool/mqueue/q2 is empty
                /var/spool/mqueue/q3 (1 request)
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------
------
f775nJF25249   230815 Tue Aug  7 14:49 <shlee at
tt.co.kr>
                 (Deferred: Connection timed out with hanmail.com)
cuwww23 at hanmail.com

위 메시지를 보면 어떠한 이유로 메일이 발송되지 못하고 있는지를 추측할 수 
있다.
3 메시지 모두 수신자의 e-mail 주소를 잘못 기입했기 때문인데, 각각 
kebi.com 인데, kebi.net 으로 unitel.co.kr 인데, unitel.net 으로 , 
hanmail.net 인데, hanmail.com 으로 도메인 주소를 잘못 기입하여 메일을 발
송하여 서버에서 메일을 발송하지 못하고 큐에 저장되어 있는 것을 확인할 수 
있다.
 여기에서 주의할 점은 mailq 명령어는 일반 유저로 실행하여 확인이 가능하므
로 퍼미션을 700 등으로 조절하여 일반 유저들은 실행할 수 없도록 하는 것이 
좋다.

>> mailstats
 mailstats 프로그램은 현재의 메일 송수신과 관련하여 통계를 보여준다.

  * 현재의 메일 통게를 보려면 아래와 같이 확인할 수 있다.

# mailstats
Statistics from Sat Aug 11 04:02:02 2001
 M   msgsfr  bytes_from   msgsto    bytes_to  msgsrej msgsdis  Mailer
 1        0          0K        3        317K        0       0  *file*
 4      690     596691K      824     137070K    68426       0  esmtp
 9       63      12212K        0          0K       27       0  local
=============================================================
 T      753     608903K      827     137387K    68453       0
 C      753                  827                68453

이를 적절히 이용하면 mrtg 를 이용해 일정 시간마다 발송되고 수신되는 메일
의 개수를 통계로 내어 그래프로 볼 수 있다.(본지 10월호, 철벽보안을 위한 
모니터링 올가이드 참조) 

최근 sendmail 관련 버그에 대해

한동안 문제가 없었던 sendmail 에 최근 들어 몇 가지 보안 문제가 발견되었
다.
이 버그는 매우 치명적인 문제인데, 아직 이를 모르고 그대로 사용중인 유저들
이 많은 것 같다. 각자의 메일 서버에는 해당사항이 없는지 꼭 확인해 보기 바
란다.

첫번째로, 8월말에 발표된 버그는 현재 대부분의 메일 서버 프로그램으로 사용
중인 sendmail 8.11.6 이전 버전에 해당하는 보안버그로서 일반유저가 Local 
에서 root 권한을 얻을 수 있는 매우 치명적인 버그인데, 이미 공격 소스가 여
러 사이트에 공개되어 있다.
참고로 이 버그는 8.11.0부터 8.11.5 버전까지만 해당하므로 8.10.x 나 8.9.x 
는 해당되지 않는다.  따라서 아래의 사이트를 참고로 sendmail 을 8.11.6 이
나 8.12등 최신버전으로 업그레이드하기 바란다. 

8.11.0부터 8.11.5 의 경우 8.11.6 으로 업그레이드하면 되고 8.12.0.Beta 의 
경우 8.12.0.Beta19 이상으로 업그레이드하면 된다. 이에 대해서는
 http://www.securityfocus.com/bid/3163 나 
http://www.sendmail.org/8.11.html
를 참고하기 바란다.

두번째는, 10월초에 발견된 버그로서  모든 버전에 해당하는 문제인데, 이전에
도 자주 나왔던 문제이다. 바로 shell 접근이 가능한 일반유저가 sendmail 
에 -q 옵션을 사용하여 큐에 있는 메시지를 드롭할 수 있는 문제이다. 아래의 
설명을 보기 바란다.

[user@net user]$ id
uid=778(user) gid=778(user) 
[user@net user]$ mailq
                Mail Queue (1 request)
--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient----------
--
NAA05248       11 Tue Oct  2 13:03 user1
                 (Deferred: Connection refused by tt.co.kr.)
                                   test at tt.co.kr

[system@net system]$ /usr/sbin/sendmail -q -h10000
Too many hops 10000 (25 max): from system via localhost, to test
at tt.co.kr
Too many hops 10000 (25 max): from MAILER-DAEMON via localhost, to
postmaster
Too many hops 10000 (25 max): from MAILER-DAEMON via localhost, to
postmaster
MAILER-DAEMON... Saved message in /usr/tmp/dead.letter
[user@net user]$ mailq
Mail queue is empty

위와 같이 hop count 를 크게 설정함으로써 일반 유저가 현재 큐의 내용을 강
제적으로 drop 시킬 수 있다.

세번째는 역시 모든 버전에 해당하는 문제로 일반 유저가 sendmail -q -d0-
xxxx.xxx 와 같이 사용시 (xxx는 디버깅 레벨이다.) 일반 유저가 메일서버의 
각종 설정 뿐만 아니라 큐에 저장되어 있는 내용, 메시지 경로나 제목, 메일 
소프트웨어등의 정보를 볼 수 있는 문제이다.
두번째,세번째 문제는 sendmail.cf 에서

O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun
와 같이 restrictqrun 를 추가함으로써 해결 가능하다.


 기타 메일과 관련된 장애가 확인 시

지난달 아파치 웹서버의 장애에 대해 이야기하면서 문제나 장애가 발생시에는 
웹서버의 error_log  메시지를 살펴보도록 이야기 했었다.  메일서버도 마찬가
지이다. 메일서버 장애시는 문제의 원인을 찾기 위해 로그 파일을 살펴보는 습
관을 들이는 것이 좋다.
메일 관련 로그는 /var/log/messages 나 /var/log/maillog 파일을 살펴보면 되
며 로그파일을 보면 여기에서 언급하지 않은 문제가 발생했다 하더리도 어렵
지 않게 원인을 찾을 수 있을 것이다.   다시 한번 강조하지만 모든 문제의 원
인과 해결책은 로그에 있다는 것을 명심하기 바란다.

글쓴이 : 좋은진호(truefeel)
글쓴날 : 2004.2
정리일 : 2004.8.10(정리)
제　목 : [튜닝] apache에서 이미지 캐싱 처리(mod_expires)


apache에서는 mod_expires 모듈을 통해 Expires HTTP header 를 설정할 수 있다. 이를 통하여 클라이언트(웹페이지 방문자)에 캐싱되는 문서나 이미지들이 많아서 트래픽을 감소시킬 수 있다. 이미지 전용 서버나 이미지 디렉토리에 설정을 해두면 효과적이다.


이미지 서버에 지정한 다음 예를 보자.



- ExpiresActive On 지시자로 Expires 설정을 enable 한다.
- ExpiresDefault "access plus 1 month" 지시자는 액세스한지 얼마나 지나서 expire할 것인지를 지정한다.
　즉, 지정한 기간만큼 클라이언트에 캐싱이 된다. 위에는 1달이다.


이외에 클라이언트에서 액세스한지 1달, 4주, 30일, 1년 등과 같은 expire 주기와
서버의 파일의 수정 시간으로 expire 주기를 설정할 수 있다.



- 설정 마지막부분에 Directory 지시자와 ExpiresActive Off 설정을 통해
　특정 디렉토리만 expire 설정에서 제외할 수 있다.
　반대로 특정 디렉토리만 On으로도 설정할 수 있다. (일반 웹서버에 /images 와 같이 디렉토리가 있는 경우)


 

- 위처럼 파일의 유형으로도 가능하다. 아주 간단하지 않는가?
참고로 [다음(daum)] 의 이미지 서버는 28일(4주)로 [야후!코리아] 는 5년으로 설정되어 있다.


* 참고 자료 : http://httpd.apache.org/docs/mod/mod_expires.html