SEROOT.COM :)

그누보드에서 룰셋에 의해 게시판 수정이 차단될때 처리방법

(neosky) — Fri, 05 Mar 2010 13:49:24 +0900

그누보드에서 룰셋에 의해 게시판 수정이 차단될때 처리방법

작성일자 : 2010년 3월 5일
작성자 : neosky (nple.com / seroot.com / neosky@smileserv.com)

1) 테스트 환경

OS : CentOS
Apache : 1.3.x
mod_security : 1.9

2) 룰셋에 의해 차단된 상태

그누보드 관리자페이지 -> 게시판관리 -> 각 게시판 수정 양식에서
다음과 같이 상단(하단)파일 경로에 상위 경로로 설정한 경우

설정 완료후 [확인] 버튼를 누르면 아래와 같이 403 에러 페이지를 만날 수 있습니다.

mod_security 룰셋에 의해 \.\ 이 들어간 구문은 공격으로 간주 차단하고 있기 때문입니다.

3) 룰셋을 우회하는 정책 설정

mod_security.conf 설정파일에 아래와 같이 차단 룰셋 전에 적어줍니다.

아파치를 재시작하고 다시 확인해보면 정상적으로 처리되는 것을 확인할 수 있습니다.

정상처리 되지만 security 로그에는 그대로 남습니다.

==51912f4a==============================
Request: test.co.kr 220.x.x.x - - [05/Mar/2010:13:30:53 +0900] 'POST /adm/board_form_update.php HTTP/1.1' 200 141 'http://nple.com/adm/board_form.php?w=u&bo_table=FREEBOARD&&sst=&sod=&sfl=&stx=&page=0' 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)' - '-'
----------------------------------------
POST /adm/board_form_update.php HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */*
Accept-Encoding: gzip, deflate
Accept-Language: ko
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 7638
Content-Type: multipart/form-data; boundary=---------------------------7da2be31105c8
Cookie: f33d2ed86bd82d4c22123c9da444d8ab=MTI2Nzc1MjUxNQ%3D%3D; 2a0d2363701f23f8a75028924a3af643=MjIwLjkwLjIxNS40; PHPSESSID=5adb9538e91a2017efd6aefeeac704f6; 96b28b766b7e0699aa91c9ff3d890663=aHR0cDovL3Rlc3QuZ29nb2F1ZGlvLmNvLmtyLw%3D%3D
Host: nple.com
Referer: http://nple.com/adm/board_form.php?w=u&bo_table=FREEBOARD&&sst=&sod=&sfl=&stx=&page=0
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
mod_security-message: Access allowed. Pattern match 'bo_include_head=(http:|https:|\\.\\.)' at POST_PAYLOAD [severity 'EMERGENCY'] <== 허용한 룰임을 밝히고 있음.

* SEROOT.COM 블로그는 맑은고딕체가 설치된 PC에서 잘 보입니다. :)

웹 방화벽 Apache mod_security 모듈 설치하기

(neosky) — Fri, 05 Mar 2010 00:59:19 +0900

웹 방화벽 Apache mod_security 모듈 설치하기

작성일자 : 2010년 3월 5일 (2010년 1월 5일 nple.net에 게시한 글을 옮기고 수정을 봄)
작성자 : neosky (nple.com/seroot.com)

1. mod_security 모듈의 개요

mod_security 모듈은 가장 널리 알려져 있는 웹 서비스 (http, https)의 공격을 효과적으로
차단할 수 있는 공개 웹 방화벽입니다.

Apache 모든 버전에서 적용에서 설치, 적용이 가능합니다.

공격 패턴의 종류로는 XSS, PHP Injection, SQL Injection, Command Execute 등이 있습니다.

2. 설치를 위한 파일 준비

- 설치환경 : Redhat Linux 계열 CentOS 5.4

- PCRE (Perl Compatible Regular Expressions)

   * 사이트 주소 : http://www.pcre.org/
   * 파일 주소 : ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.00.tar.gz
   (2010년 1월 현재 최신 버전은 8.00)

- mod_security

   * 사이트 주소 : http://www.modsecurity.org/
   * 파일 주소 : http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz
   (2010년 2월 현재 최신 버전은 2.5.12 이나 설치후 아파치 시작시 먹통되는 증상이 있음)

3. 설치를 위한 조건사항

mod_security 모듈을 설치하기 위해서 먼저, apache 데몬이 서버에 설치되어 있어야 합니다.
(apr, apu 명령을 사용하기 위함)

그리고, 서버에 PCRE 라이브러리가 설치되어 있어야 합니다.

4. PCRE 라이브러리 설치

작업하기 위한 공간으로 /usr/local/src 디렉토리에 프로그램을 다운로드 받습니다.
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.00.tar.gz

다운로드 받은 파일의 압축을 풉니다.
tar xvfz pcre-8.00.tar.gz

디렉토리에 접근해 라이브러리를 설치합니다.
cd pcre-8.00
./configure --prefix=/usr/local/pcre
make
make install

5. mod_security 모듈 설치

작업하기 위한 공간으로 /usr/local/src 디렉토리에 프로그램을 다운로드 받습니다.
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.11.tar.gz

다운로드 받은 파일의 압축을 풉니다.
tar xvfz modsecurity-apache_2.5.11.tar.gz

디렉토리에 접근해 모듈을 설치합니다.
cd modsecurity-apache_2.5.11/apache2/

아파치 버전에 따라 설치 옵션을 달립니다.

Apache 2.0
./configure --with-apxs=/usr/local/apache/bin/apxs --with-pcre=/usr/local/pcre --with-apr=/usr/local/apache/bin/apr-config --with-apu=/usr/local/apache/bin/apu-config

Apache 2.2
./configure --with-apxs=/usr/local/apache/bin/apxs --with-pcre=/usr/local/pcre --with-apr=/usr/local/apache/bin/apr-1-config --with-apu=/usr/local/apache/bin/apu-1-config

make
make install

6. 아파치 환경파일 (http.conf) 추가

아파치 환경파일을 열어 위에서 설치한 모듈을 불러드립니다.
LoadModule security2_module modules/mod_security2.so

그리고, 파일 맨 하단에 다음 문을 추가합니다.
차후 다운로드 받을 룰셋 파일을 불러드리기 위함입니다.

# mod_security roll include
Include conf/mod_security.conf

7. KISA에서 배포하는 룰셋 다운로드

한국정보보호진흥원(KISA)에서 mod_security 룰셋을 공개 배포하고 있습니다.
* 사이트 : http://toolbox.krcert.or.kr/MMVF/MMVFView_V.aspx?MENU_CODE=8&PAGE_NUMBER=13

왼쪽 메뉴중 공개웹방화벽 -> ModSecurity 자료실 클릭해서
ModSecurity용 차단 샘플룰 [`09.03.11] 게시물의 파일을 다운로드 받습니다.

서버 /usr/local/apache/conf 위치에 업로드해서 mod_security.conf 이름으로 변경해서
사용하면 되고, 이후 설정방법은 같이 다운로드 받은 압축파일 내 파일을 참조합니다.

Apache 1.3.x 은 ModSecurity_1x_hosting_090311.conf 룰셋 사용
Apache 2.x 이상은 ModSecurity_2x_hosting_09311.conf 룰셋 사용

샘플 룰은 초기 설정이 실제 차단하는 것으로 되어 있지 않으므로,
커스터마이징 후 적용하도록 합니다.

8. 아파치 재시작

위 모든 과정을 마쳤으면, 아파치를 재시작합니다.
/etc/init.d/apachectl restart

[mod_security 설치후 apache error log 에 다음 내용이 남는다면!!]

[error] ModSecurity: ModSecurity requires mod_unique_id to be installed.

아파치 소스 있는 곳으로 가서 아래 명령을 내려주고
/usr/local/apache/bin/apxs -cia mod_unique_id.c

아파치를 재시작합니다.
/etc/init.d/apachectl restart

소스가 없다면 같은 apache 버전 다운로드후 압축을 풀고
위와 같이 명령내려주고, 아파치를 재시작합니다.

* SEROOT.COM 블로그는 맑은고딕체가 설치된 PC에서 잘 보입니다. :)

lsof 의 실전 사용 [펌]

(neosky) — Thu, 18 Feb 2010 13:21:32 +0900

이 글은 lsof 의 사용방법에 대해 설명합니다. lsof 는 프로세스의 파일핸들을 조사해 볼 수 있는 유용한 툴입니다.

lsof ("LiSt Open Files") 는 서버에 열린 파일 핸들의 리스트를 보여주는 툴입니다. 여러가지 옵션들과 스위치들을 통해서 이러한 핸들들을 필터링할 수 있게 해줌으로써 솔라리스 관리자가 문제에 대한 분석을 가능하도록 도와 줍니다.

이 가이드는 lsof 의 몇가지 커맨드라인 옵션에 대해 설명합니다. 그리고 실전에서 어떻게 lsof 를 사용할 수 있는지에 대한 몇가지 예제를 보여 드립니다. (참고: 이 글의 모든 예제는 솔라리스 8 버전 이상에서 모두 적용 가능합니다; 이전 버전에서도 사용이 가능할 것으로 생각되지만 직접 확인해 보진 않았습니다.)

"lsof" 얻기

lsof 는 기본 솔라리스 설치의 표준으로 따라서 설치되지 않습니다. 그러나 SPARC 및 x86 버전의 솔라리스 패키지로 컴파일 가능하고 http://sunfreeware.com 에서 다운로드 받으실 수 있습니다.

열린 네트워크 포트 확인하기

구문:

 
lsof -i [<protocol>][@<interface name>][:<port>]

위의 3가지 파라미터를 일부분만 혹은 전부 지정하실 수 있습니다. 생략된 부분은 와일드카드로 간주 합니다. <port> 는 단일 포트 혹은 범위로 지정될 수 있습니다. lsof 를 이러한 방식으로 사용하는 것은 netstat -a 와 비슷한 결과를 돌려주지만 거기에 덧붙여서 프로세스와 소유자의 정보 또한 제공 합니다.

주어진 프로세스가 연 파일 핸들들의 리스트

구문:

 
lsof -p <process id>[,<process id>[,<process id>[...]]]

lsof 에 하나 혹은 복수개의 프로세스 ID 를 (콤마로 구분됨) 입력함으로써 모든 연관된 파일 핸들들의 리스트를 출력할 수 있습니다. 이것은 특정 실행 프로세스가 어떠한 라이브러리를 사용하는지 확인할때 아주 유용합니다. 이 커맨드를 통해서 프로세스가 어떻게 로그 파일, 설정 파일들과 상호동작하는지 확인하실 수 있습니다.

특정 유저가 연 파일 핸들들의 리스트

구문:

 
lsof -u <username>[,<username>[,<username>[...]]]

이 커맨드는 주어진 유저에게 속한 모든 열린 핸들들을 보여 줍니다.

주어진 파일 시스템에서 열린 모든 파일 핸들들 보기

구문:

 
lsof <file system or device>

이 옵션은 umount 커맨드가 수행되는 것을 막는 프로세스들을 찾을때 유용합니다. 혹은 적절한 디렉토리 항목에 없는 열린 파일을 추적할때에 유용합니다.

다른 유용한 플래그들

-b – 커널을 블록할 수 있는 시스템 호출의 사용 회피하기
-w – 주의 메세지 생략하기
-P – 포트 번호를 /etc/services 에 있는 서비스 이름들과 매핑하지 말기
-a – 이 플래그를 다른 두 플래그 사이에 삽입함으로써 두가지 플래그 모두에 매치되는 결과만 보기. 기본적으로 lsof 는 지정된 플래그들 중에 하나라도 만족하는 모든 핸들들을 보여줌.

예제

inetd 가 리스닝하고 있는 모든 포트들 보기:
현재 inetd 가 어떠한 포트들을 열고 있는지 확인해 봅시다.

 
gouda# ps -ef | grep inetd
 
root  2849     1  0   May 25 ?        6:43 /usr/sbin/inetd -s
gouda# lsof -i -a -p 2849
COMMAND  PID USER   FD   TYPE        DEVICE SIZE/OFF NODE NAME
inetd   2849 root   11u  IPv6 0x30006ec96d0      0t0  TCP *:ftp(LISTEN)
inetd   2849 root   13u  IPv4 0x30006ec9550      0t0  UDP *:name(Idle)
inetd   2849 root   16u  IPv4 0x30008f26ad8      0t0  TCP *:52783(LISTEN)
inetd   2849 root   17u  IPv4 0x30006ec9b50      0t0  UDP *:57504(Idle)
inetd   2849 root   23u  IPv6 0x30008f264d8      0t0  UDP *:servicetag(Idle)
inetd   2849 root   24u  IPv4 0x30008f26358      0t0  TCP *:servicetag(LISTEN)

일단 inetd 의 프로세스 ID 를 확인하고, 그 다음 lsof 가 모든 IP 핸들들과 (-i) 또한 (-a) 와 같이 포트에 의해 열린 것들을 (-p <process id>) 확인합니다.

특정 유저의 현재 열린 모든 네트워크 접속의 리스트:
가능한 보안 구멍을 추적하거나 어플리케이션이 올바른 데이타베이스에 접속하고 있는지 확인하기 위해서, lsof 는 주어진 유저의 현재 네트워크 접속들을 보여 줍니다.

 
gouda# lsof -i -a -u fred
COMMAND PID USER FD  TYPE DEVICE SIZE NODE NAME
sshd   9696 fred  5u IPv4 0x3001 0t527 TCP gouda:22->edam:46528(ESTABLISHED)
sshd   9696 fred 10u IPv4 0x300e   0t0 TCP localhost:6011(LISTEN)
sshd  14710 fred  5u IPv4 0x3008 0t404 TCP gouda:22->edam:46590(ESTABLISHED)
sshd  14710 fred 10u IPv4 0x307d   0t0 TCP localhost:6012(LISTEN)
sshd  17013 fred  5u IPv4 0x300f 0t146 TCP gouda:22->edam:50019(ESTABLISHED)
sshd  17013 fred 10u IPv4 0x30e0   0t0 TCP localhost:6010(LISTEN)
ssh   25259 fred  4u IPv4 0x3000 0t157 TCP gouda:54435->colby:22(ESTABLISHED)
sshd  25383 fred  5u IPv4 0x3000 0t126 TCP gouda:22->brie:34480(ESTABLISHED)
ssh   25438 fred  4u IPv4 0x3000  0t91 TCP gouda:54448->smokey:22(ESTABLISHED)

이 것은 fred 란 유저가 3개의 수신(incoming) ssh 접속을 가지고 있고 두개의 송신 ssh 접속을 가지고 있음을 알려 줍니다. lsof 를 다른 서버중에 하나에서 실행하고, 본래 포트를 찾아 봄으로써 (예를 들어 edam 의 포트 46528) 거기서 계속적으로 추적을 수행할 수 있습니다.

어떤 프로세스가 특정 파일 시스템의 언마운트를 막는지 찾아보기:
특정 프로세스가 umount 커맨드의 수행을 방해할 수 있습니다. -f 플래그를 통해서 잠재적으로 오류를 유발하는 대신에 lsof 는 어떠한 프로세스들이 먼저 정지 되어야 하는지를 보여 줍니다.

 
gouda# lsof /mnt/scratchdisk
COMMAND   PID USER    FD  TYPE DEVICE SIZE/OFF NODE NAME
bash     7268 fred    cwd VDIR 85,204      512    2 /mnt/scratchdisk/edam
dcm     15375 george  txt VREG 85,204   292352  202 /mnt/scratchdisk/bin/dcm
dcm     15375 george  cwd VDIR 85,204      512    5 /mnt/scratchdisk/bin/dcm

결과는 fred 가 배시 쉘을 가지고 있고 우리의 마운트 포인트 위에서 작업하고 있음을 보여 줍니다. 그리고 george 가 동일한 파일 시스템상의 다른 디렉토리에서 dcm 의 복사를 시작하였습니다.

특정 포트에 어떠한 프로세스가 리스닝하고 있고 누가 이 포트를 사용하고 있는지 보기:
포트가 이미 사용되고 있습니다(port already in use) 오류 때문에 데몬이 시작되지 않을때 관리자는 종종 좌절하게 됩니다. lsof 는 어떤 프로세스가 우리가 사용하고자 하는 포트를 사용하고 있는지 추적하기 위해 사용될 수 있습니다.

 
gouda# lsof -i :7507
COMMAND  PID   USER FD  TYPE  DEVICE  SIZE NODE NAME
inetd    668   root 34u IPv4 0x303f0   0t0  TCP *: 7507 (LISTEN)
answer 19757 nobody  0u IPv4 0x58028 0t132  TCP gouda:7507->edam:46111 (ESTABLISHED)
answer 19757 nobody  1u IPv4 0x58028 0t132  TCP gouda:7507->edam:46111 (ESTABLISHED)
answer 19757 nobody  2u IPv4 0x58028 0t132  TCP gouda:7507->edam:46111 (ESTABLISHED)

위의 결과로 볼때 inetd 가 answer 라는 서비스를 그 포트에서 실행하고 있고 edam 에서 실행되는 어떤 것이 접근하고 있음을 알 수 있습니다.edam 에서 lsof -i :46111 를 수행하여 어떠한 프로세스 인지를 확인해 봅니다.

해당되는 디렉토리 항목이 없는 열린 파일을 참조하는 프로세스 찾아내기:
만약 어떤 유저가 실행중인 프로세스가 참조하는 파일을 지웠다면, 파일 시스템은 실제로 마지막 링크가 닫힐때 까지 이 파일을 삭제하지 않습니다. 이러한 경우 실행중인 프로세스만이 남게 됩니다. 만약 이 프로세스를 찾을 수 있다면 우리는 해당 프로세스를 닫거나(파일이 삭제되길 원할때) 혹은 파일을 다시 살려야 할때 /proc 파일 시스템(솔라리스 8 이상) 을 통해서 파일의 내용을 저장할 수 있습니다.

 
gouda # df -k /opt/myapp/data
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d100     4129290 1458133 2629865    36%    /opt/myapp
 
gouda # lsof /opt/myapp | grep '/dev/md/dsk/d100'
less      15043 fred    4r  VREG  102,0       144 2050050 /opt/myapp (/dev/md/dsk/d100)

위의 결과는 파일이 less (프로세스 ID 15043) 에 의해 열려져 있음을 알려 줍니다. 만약 파일을 삭제하는 것이 목표라면 less 프로세스를 종료 시킴으로써 원하는 작업을 수행할 수 있습니다. 만약 파일의 내용을 다시 살리는게 목표라면, 복사를 통해서 가능합니다. 4번째 컬럼은 파일 디스크립터 4번에 읽기 전용 핸들을 보여 줍니다. 이것은 /proc/15043/fd/4 를 읽음으로써 파일의 내용을 다시 살릴 수 있음을 의미 합니다.

이 글의 영문 원본은
wikis.sun.com Using "lsof" in the Real World
에서 보실 수 있습니다.

HeartBeat를 이용한 MySQL HA 구성 (펌)

(neosky) — Wed, 17 Feb 2010 11:22:16 +0900

인터넷이 발전하고, 인터넷을 사용한 서비스가 발전함에 따라 24시간 서비스를 운영하기 위한 각 서비스 제공 회사들의 노력은 증가하고 있다. 이에 발맞춰 애플리케이션뿐 아니라 DB 레벨에서도 더 좋은 성능으로 24시간 운영하기 위한 여러 가지 솔루션이 발표되고 있다. MySQL AB도 이런 요구에 부응하기 위해 HA를 위한 솔루션을 개발 중이며, HA 구성법도 여러 가지로 다양해지고 있다. MySQL Cluster를 이용해 구성할 수도 있고, MySQL Proxy, DRBD 등을 이용해 구성할 수도 있다. 이 글에서는 MySQL HA 구성 중에 MySQL Replication과 HeartBeat를 이용해 구성하는 방법을 설명한다.

윤은경 joanney1@daum.net, mysqldba.tistory.com, blog.daum.net/joanney｜다음커뮤니케이션 DB기술팀 MySQL Cell 소속. 대학 졸업 후 5년 동안 자바 개발자로 살다가, 갑자기 맘이 바뀌어 그 후 5년간 DBA로 살고 있는, 10년 차 직장인이 됐다는 게 여전히 믿겨지지 않는 IT 종사자이다.

MySQL HA 구성
HeartBeat를 이용한 HA 구성에는 다음과 같은 모듈이 필요하다.

● HeartBeat - 두 서버 사이에 Fail-Over를 가능하게 하는 모듈
● Mon - MySQL Instance의 서비스 가능 여부를 체크하는 체크 모듈
● MySQL Dual Replication - 원활한 Fail-Over 및 Fail-Back을 위한 Replication 구성

HeartBeat
HeartBeat는 Linux-HA 프로젝트 그룹에서 만든 모듈로서 리눅스 운영체제에서 고가용성을 제공한다. HeartBeat는 위에서 간단히 설명한 대로 두 서버 사이에 Fail-Over를 가능하게 하는 모듈로서 서버 사이의 Fail-Over 기능을 제공하고자 할 때 사용한다.

HeartBeat의 구성
HeartBeat를 설치하면 두 서버 사이에 즉, Primary로 설정된 서버와 Standby로 설정된 서버 사이에 주기적으로 메시지를 교환해 서버의 상태를 확인한다. 이때 주고받는 메시지를 ‘heartbeat’ 즉 한글로 ‘심장박동’이라고 한다.

HeartBeat는 Active로 사용 중인 Primary 서버와 Passive 상태인 Standby 서버 사이에 IP 관리 기능의 일환으로, VIP를 사용해 Active 상태인 Primary 서버에 장애가 일어나더라도 Passive 상태인 Standby 서버를 이용해 서비스가 진행될 수 있도록 한다.

애플리케이션에서는 VIP를 사용해 서버에 접근한다. 이때 VIP로 접근하는 애플리케이션은 HeartBeat 구성에서 Active로 설정된 Primary 서버에 자동으로 접근하게 된다. 만약 서버가 reboot되거나 문제가 발생해 사용하지 못하는 상태가 되는 경우 HeartBeat이 감지해 현재 문제가 발생한 Primary 서버가 아닌 Standby 서버를 Active로 전환해 서비스가 계속 이어지게 한다.

HeartBeat의 특성 및 제약 사항

HeartBeat는 다음과 같은 특성 및 제약 사항을 가진다.

- 리눅스 서버상의 Fail-Over 기능을 제공하고 리눅스 운영체제에서만 사용할 수 있다. HeartBeat 모듈은 리눅스-HA 프로젝트 그룹에서 만든 모듈이기 때문에 리눅스 운영체제에서만 동작하는 모듈이다. 그렇기 때문에 다른 운영체제를 사용하는 시스템에서는 사용이 불가능하다.
- 간단한 설치로 사용이 용이하다.
- 시스템 레벨(System Level)이 아닌 애플리케이션 레벨(Application Level)에서의 Fail-Over는 할 수 없다. HeartBeat는 VIP를 이용해 두 개의 서버 사이의 특정 서버만 접근 가능하게 하는 모듈이기 때문에 시스템 레벨만 가능할 뿐 HeartBeat 자체적으로는 애플리케이션 레벨의 Fail-Over가 불가능하다. 즉, 애플리케이션 레벨의 Fail-Over를 위해서는 추가적인 모듈이 필요하다.
- HeartBeat 구성을 위한 추가적인 장비가 필요하지 않다. HeartBeat은 Active와 Passive를 사용하는 두 서버 사이의 설정으로 사용하는 모듈이기 때문에 추가적인 장비가 필요하지 않다.

Mon
Mon은 이벤트를 이용해 서비스에 대한 사용을 모니터링하는 모듈이다. Mon은 시스템을 ping 프로그램을 이용해 모니터링하는 것과 같은 간단한 경우에서부터 DB 서버에 대한 모니터링까지 가능한 모니터링 모듈로서 HeartBeat과 같이 쓰여서 리눅스 상에서 Fail-Over를 구현할 수 있는 모듈이다.

Mon의 구성 및 동작 프로세스

MySQL 프로세스의 감지를 위해 Mon을 사용하는 경우 <그림 3>과 같은 프로세스로 모니터링이 진행된다.

먼저 Mon 실행 스크립트를 작성해 MON 프로세스를 띄운다. MON은 설정 파일(mon.cf)에 저장된 값을 이용해 주기적으로 mysql.monitor를 실행한다(mysql.monitor는 MySQL과 MSQL을 모니터링하기 위해 제공되는 스크립트인 msql-mysql.monitor의 이름을 수정한 것이다). mysql.monitor는 주기적으로 호출될 때마다 MySQL 프로세스를 체크하고, mysql.monitor가 체크시 MySQL 프로세스의 문제점을 확인하게 되면 bring-ha-down.alert를 호출하게 된다. bring-ha-down.alert는 MySQL 프로세스 문제 시 동작하는 스크립트 파일로서 이 파일에서 Fail-Over를 위해 HeartBeat 모듈을 호출하게 된다. 즉, bring-ha-down.alert은 HeartBeat를 호출하는 스크립트로서 이 스크립트를 통해 HeartBeat와 연결되어 동작한다. 이 스크립트는 Mon 모듈에 속한 게 아니라 사용자가 직접 생성해야 한다.

Mon의 특성 및 제약 사항
Mon은 다음과 같은 특성 및 제약 사항을 가진다.

- 여러 가지 애플리케이션 및 하드웨어의 장애를 감지하는 모니터링 툴이다. Mon은 다방면에서 사용할 수 있는 모니터링 모듈로서 MySQL 프로세스뿐 아니라 MSQL 프로세스 모니터링, 그리고 각종 하드웨어 모니터링까지 가능한 모듈이다. 여기에서 우리는 MySQL에 대한 모니터링 기능 부분만 사용한다.
- 간단한 스크립트 작성으로 사용하기가 간편하다. 위에서 설명한 것과 같이 간단한 스크립트 작성으로 모니터링 시 문제 해결을 위한 여러 기능을 구현할 수 있고, 원하는 대로 사용할 수 있다.
- 실질적인 Fail-Over를 발생시키는 모듈이 필요하다. 앞서 설명한 대로 Mon은 모니터링 모듈이기 때문에 Fail-Over를 위해서는 Mon뿐 아니라 추가적인 모듈이 필요하고, 그래서 여기서는 Fail-Over를 위한 모듈, 즉 HeartBeat과 같이 사용한다.

MySQL Replication
MySQL Replication은 MySQL Server 4.0에서부터 사용 가능한 HA 솔루션으로 가장 쉽게 구성할 수 있고, 가장 많이 사용하고 있는 솔루션이다. MySQL Replication은 다른 특별한 설치 과정이 필요 없이 MySQL 서버의 설치만으로 사용할 수 있고 구성하기 쉽기 때문에 누구나 쉽게 설치해 사용할 수 있다. 또한 제약사항이 적고 구성하는 프로세스가 간단하기 때문에 여러 구성으로 사용하는 것이 가능하다.

Replication의 구성

MySQL은 <표 1>과 같은 Thread를 통해 Replication을 운영한다.

MySQL은 <표 1>의 세 가지 프로세스를 비동기적으로 실행해 Replication이 진행되도록 한다. Replication은 이 세 개의 Thread만으로 동작하며 다른 임의의 프로세스가 존재하지 않는다. MySQL Replication의 동작은 <그림 4>와 같이 설명할 수 있다.

Slave에서 start slave 명령어가 실행되면 Master와 Slave에는 각각 Binlog Dump Thread와 I/O Thread, SQL Thread가 생성된다. 그리고 Binary log가 생성될 때마다 Binlog Dump Thread는 Binary Log를 Slave로 보낸다. 이때 Slave의 I/O Thread는 받은 Binary Log를 Relay Log로 기록하게 되고, SQL Thread는 이렇게 새롭게 기록된 내용을 읽어서 Slave에서 실행하게 된다. HeartBeat를 이용한 MySQL Replication은 일반적인 Replication이 아닌 Dual-Master 구성을 사용한다.

Dual-Master Replication
두 대의 서버가 동시에 Master/Slave의 역할을 수행하는 구성을 의미한다.

이 구성은 두 대의 서버가 인스턴스로 Replicate되는 구성으로 동시에 두 대의 서버가 Master/Slave로서의 역할을 수행하는 구성이다.

● 특징

- 두 서버가 서로 Replication으로 연결된 구조로서 어느 서버에서든지 DML을 발생시켜도 다른 서버에 Replicate되어 전달된다. 두 서버가 동시에 Master이자 Slave이기 때문에 각 서버에서 발생된 DML은 다른 서버로 이동하게 되고, 결국 같은 DML이 두 서버에서 다 발생하게 된다.
- 두 대의 서버가 같은 스키마와 데이터를 가진 구조이다. 앞에서 설명한 대로 두 서버의 DML이 Replicate되어 양 서버에서 다 발생하기 때문에 같은 스키마와 데이터를 가진 구조가 된다.

● 장점

- HeartBeat/Mon을 이용한 HA 구성으로 사용할 경우 Fail-Over, Fail-Back에 유연한 대처가 가능하다. 이론적으로 두 서버가 동시에 Master와 Slave로 연결된 구조이기 때문에 단 방향으로 연결된 Replication 구조에 비해 Fail-Over, Fail-Back에 유연하게 대처할 수 있다. 물론, 안전한 Fail-Over, Fail-Back을 위해서는 Fail-Over, Fail-Back에 대한 프로세스는 간단하지 않다. 하지만, 단 방향 구조에 비해 그 프로세스는 간단하게 된다. 또한, HeartBeat에 의해 두 서버 중 하나의 서버만 실질적으로 서비스에 사용되기 때문에 뒤에서 설명할 Dual-Master 구조의 치명적인 단점에서 자유롭다.
- 어느 서버에 DML이 발생해도 다른 서버로 Replicate가 가능하다. 앞서 설명한 대로 양 방향으로 연결된 구조이기 때문에 두 서버 중 어느 서버에 DML이 발생해도 다른 서버에 Replicate되어 DML이 전달된다.

● 단점

- 두 서버에서 동시에 같은 데이터에 DML이 발생하는 경우 데이터의 불일치 발생 가능성이 높다. Dual-Master 구조의 특징으로 두 서버가 같은 스키마와 데이터를 가진다고 설명했다. 하지만 Dual-Master 구조는 그 구성에 치명적인 문제를 가지고 있다. 바로 DML 발생에 따라 데이터 불일치가 발생할 수 있다는 것이다.
- DML 분산이 되는 것처럼 착각할 수 있으나, DML 분산은 실질적으로 발생하지 않는다. Replication 동작 프로세스를 통해 알 수 있는 것처럼 Master에서 실행된 Query를 Slave에서도 똑같이 동작하게 해 데이터를 일치화시키는 솔루션이므로, 실질적으로 두 서버의 DML이 분산되는 것은 아니다.

Configuration
이제 앞에서 설명한 모듈들을 사용한 전체 구성에 대해 알아보도록 하자. 여기서는 Replication을 이용해 HA 구성을 하게 되는데, Replication 중 앞에서 설명한 Dual-Master Replication 구성을 사용한다.

Dual Master 구조에서의 데이터 불일치 케이스

Dual Master 구조에서 컬럼의 값에 동시에 DML 쿼리가 실행된다고 가정해 보자.

먼저 각각 서버에서 update 문이 실행되기 때문에 처음에 server1은 1, server2는 2로서 값이 변경된다. Commit이 진행된 후 Binary log에 작성되고 각각 서버에서 실행된 Query는 BinlogDump Thread에 의해 server2, server1으로 이동하게 된다.

그 후에 Replication으로 넘어온 SQL 문이 실행되는 경우 값은 다시 server1은 2로 server2는 1로 바뀌게 된다. 결국 server1의 값은 2로, server2의 값은 1로 남게 된다.

HeartBeat + Mon
HeartBeat와 Mon은 모두 무료로 사용할 수 있는 모듈이다. HeartBeat은 서버의 Fail-Over 기능을 제공하고 Mon은 MySQL 프로세스를 모니터링하는 기능을 제공하기 때문에 두 개의 모듈을 함께 사용해야만 완전한 Fail-Over 기능을 구현할 수 있다.

● 특징

- 다른 특별한 기기 없이 모듈 설치만으로 Fail-Over가 가능하다.
- 안전한 구성을 위해 추가적인 스크립트 생성이 필요하다.
- 리눅스 운영체제에서만 사용이 가능하다.

Dual Master Replication + HeartBeat + Mon
MySQL은 Dual Master 구조로 데이터를 실시간으로 복제한다. Mon은 실시간으로 MySQL의 상태를 체크해 모니터링하고 만약 MySQL 서버에 문제가 발생하면 그것을 감지하고 HeartBeat를 호출해 Fail-Over가 이뤄지게 한다. Fail-Over가 일어난다 할지라도 애플리케이션에서는 VIP를 통해 접근하기 때문에 문제없이 서비스를 지속할 수 있다.

이 구조에서 두 서버의 MySQL은 Dual Master 구조로 되어 있지만, HeartBeat 설정을 통해 애플리케이션은 VIP를 이용해 두 서버 중 하나의 서버에만 접근할 수 있으므로 구조적으로 가지는 Dual-Master의 문제점을 피할 수 있다. 여기서 설명한 HA 구성에서 문제 발생시 동작하는 프로세스를 정리하면 <그림 9>와 같다.

여기서 살펴본 HA 구성의 특징을 정리하면 다음과 같다.

● 특징

- Fail-Over를 하기 위한 별도의 장비가 필요하지 않다.
- Replication이 가능한 어떤 스토리지 엔진을 사용하든 구성할 수 있다.
- MySQL Community 버전 설치만으로 사용할 수 있다.
- 구성할 수 있는 두 대 중 한 대는 VIP를 사용해 서비스용으로 사용할 수 없다.
- Passive 상태의 Standby 서버를 물리적인 IP로 접근해 사용할 수는 있지만, 앞서 설명했던 Dual-Master의 데이터 불일치 가능성으로 인해 권장하지는 않는다.
- Fail-Over된 원인에 따라 Active로 사용하던 서버의 변경내역이 Replicate 되지 않을 수 있기 때문에, Replication에 대한 분석 프로세스가 추가되어야 한다.
- 리눅스 운영체제에서만 구성할 수 있다.
- HeartBeat 구성의 제약으로 인해 Fail-Over가 발생하면 꼭 Fail-Back 진행을 해줘야 한다.
- DB 레벨의 Fail-Over는 Heart-Beat/Mon 조합으로 가능하게 되었지만, 세션 레벨의 Fail-Over는 구현되지 않았기 때문에, Fail-Over 발생 시 애플리케이션의 DB Connection을 refresh하는 작업을 해야 한다.

맺음말
여기서 설명한 내용은 MySQL에서 구현할 수 있는 HA 구성 방법 중 하나로서 현재 필자는 이와 같은 구성으로 구현해 서비스에 투입한 후 사용하고 있다. 여기에서는 자세한 설치법보다는 각각 모듈의 개념 및 프로세스 설명에 주안점을 두어 설명했다. 이와 같은 내용을 먼저 알아두고 실제 설치 작업을 진행한다면 훨씬 더 쉽게 구현할 수 있다.

출처 : http://imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33696

qmail FAQ

(neosky) — Tue, 02 Feb 2010 09:13:37 +0900

qmail.kldp.org FAQ #

자주 질문되는 것을 정리합니다. -- 임은재 2004-04-15 13:33:05

1 qmail.kldp.org FAQ

1.1 double bounce 메세지를 받고 싶지 않다면?
1.2 특정 계정으로 오는 메일을 큐잉(queueing)하지 않고 거부 하려면?
1.3 자동 응답기를 사용하고 싶다면?
1.4 큐안의 메일을 안전하게 삭제하려면?
1.5 서버를 통해 외부로 나가는 모든 메일의 헤더를 자동으로 수정하고 싶다면?
1.6 특정 계정으로 오는 메일을 삭제하려면?
1.7 큐 디렉토리를 복구하려면?
1.8 포워딩 되는 메일에 Reply-To 헤더를 붙이려 합니다.
1.9 특정 도메인으로의 발송을 제한 하려면?
1.10 qmail-smtpd가 제대로 작동하지 않고 연결이 즉시 종료됩니다.
1.11 스크립트 작성시 가장 실수가 많은 것
1.12 외부로 부터 메일 수신이 안됩니다.
1.13 vpopmail 가상 계정의 POP 인증이 안 됩니다.
1.14 glibc 2.3.1 이상에서 qmail 컴파일이 안 됩니다.
1.15 릴레이가 허용되고 있지 않은데도 qmail-remote 프로세스가 많습니다.

1.1 double bounce 메세지를 받고 싶지 않다면? #

1. 더블 바운스는 바운스된 메세지가 다시 바운스되는 경우인데 일반적으로 이 메세지는 postmaster로 배달되도록 되어 있다.

이것은 control/doublebounceto와 doublebouncehost를 사용하여 조정할 수 있는데 예를 들어 더블 바운스 메세지를 자동으로 삭제되도록 하려면 다음과 같이 null 계정을 하나 만들고 그 계정으로 배달되도록 한다

$ echo "#" > ~alias/.qmail-doublebounce
$ echo "doublebounce" > /var/qmail/control/doublebounceto

2. 두번째 방법은 다음 패치를 적용하는 것인데, 이렇게 패치된 qmail-send는 더 이상 메세지를 큐에 저장하지 않으므로, 매우 많은 double bounce 메세지가 발생할 경우 더 효과적일 수 있다.

doublebounce-trim.patch

패치/컴파일/재설치가 끝났다면 다음과 같이 빈줄만을 포함한 doublebounceto 파일을 만든다.

   $ echo -e "\n" > /var/qmail/control/doublebounceto

1.2 특정 계정으로 오는 메일을 큐잉(queueing)하지 않고 거부 하려면? #

특정 계정으로 도착하는 메일을 큐에 넣기 전에 qmail-smtpd에서 미리 거부하는 것은 바운스 메일이 발생하지 않는다는 장점을 가진다.

이것이 가능하도록 하려면 badrcptto.patch를 사용하여 qmail-smtpd를 다시 컴파일 하고 /var/qmail/control/badrcptto 에 거부할 주소를 넣어 두면 된다. (이 패치는 릴레이가 허용된 곳이나 로컬에서는 원래 적용되지 않습니다).

1.3 자동 응답기를 사용하고 싶다면? #

autorespond를 사용합니다. 마지막 버전은 http://inter7.com/qmailadmin/ 에서 구할 수 있습니다. 컴파일/설치가 끝나면, 해당 사용자의 .qmail 파일을 다음 형식으로 만듭니다.

/home/user/Maildir/
|/usr/local/bin/autorespond 10000 5 /home/user/vacation.message /home/user/messagelog/

1.4 큐안의 메일을 안전하게 삭제하려면? #

1. 큐 디렉토리 전체를 지웠다가 다시 만들고자 한다면, Eric Huss가 만든 queue-fix를 사용하는 것이 좋습니다. 큐메일 프로세스들을 모두 정지 시키고, 큐 디렉토리를 삭제한 후 queue-fix /var/qmail/queue 하면 다시 큐가 다시 만들어 집니다.

2. 큐에 있는 특정 메일만 삭제하려 한다면, qmHandle을 사용합니다. 큐에 있는 모든 메일을 삭제하려면 qmHandle -D, 특정 메일만 삭제하려면 일단 큐에 있는 메일의 목록을 보고 qmHandle -l, 번호를 지정하여 삭제합니다. qmHandle -d12345

※ queue-fix 설치법

tar xzf queue-fix.tar.gz
cat ../queue-fix-1.4.diff | patch -p1
make
rm -rf /var/qmail/queue
./queue-fix -i /var/qmail/queue

1.5 서버를 통해 외부로 나가는 모든 메일의 헤더를 자동으로 수정하고 싶다면? #

mess822 패키지의 ofmipd를 사용하면 가능합니다.

1.6 특정 계정으로 오는 메일을 삭제하려면? #

계정이 foobar 라고 한다면,

$ echo "#" > ~alias/.qmail-foobar
또는
$ echo "#" > ~foobar/.qmail

1.7 큐 디렉토리를 복구하려면? #

qmail 큐 디렉토리를 새로 만들거나 복구 하려면 queue-fix를 사용합니다. http://www.netmeridian.com/e-huss/queue-fix.tar.gz. 예를 들어 큐 디렉토리를 새로 만들려면 qmail을 종료 시킨후,

$ rm -rf /var/qmail/queue/
$ queue-fix /var/qmail/queue

glibc-2.3.1이상에서는 다음 패치를 적용 후 컴파일 합니다. queue-fix-1.4.diff

1.8 포워딩 되는 메일에 Reply-To 헤더를 붙이려 합니다. #

.qmail을 다음과 같은 요령으로 작성합니다.

| (echo "Reply-To: me@domain.org"; cat) | forward me@domain.org

1.9 특정 도메인으로의 발송을 제한 하려면? #

예를 들어 서버를 통해 발송되는 메일중 test.com 도메인으로 발송되는 메일만을 제한 하려면 /var/qmail/control/virtualdomains 파일에 다음을 추가하고,

test.com:null

.qmail-null 파일을 만든다.

   $ echo "#" > /var/qmail/alias/.qmail-null

이제 test.com 으로 발송되는 메일은 로컬 null 계정으로 배달될 것이고, .qmail-null 파일의 내용에 의해 삭제될 것이다.

1.10 qmail-smtpd가 제대로 작동하지 않고 연결이 즉시 종료됩니다. #

qmail-smtpd가 실행되고 있지만 SMTP 포트로 접근시 연결이 즉시 종료된다면 다음 두가지를 확인해 봅니다.

1. qmail-smtpd 구동 스크립트 (/var/qmail/supervise/qmail-smtpd/run)에 사용한 리소스 제한값 (softlimit -m)을 바꿔봅니다. 예를 들어 2000000 였다면 7340032 정도록 올려 봅니다.

2. qmail-smtpd 구동 스크립트에서 tcpserver 옵션중 tcprules 파일을 사용하고 있다면 (예: -x /etc/tcp.smtp.cdb ) 이 파일이 읽을 수 있는 권한인지 확인해 봅니다.

1.11 스크립트 작성시 가장 실수가 많은 것 #

qmail 설치시 만드는 스크립트에는 특정 그룹이나 사용자 권한을 사용하기 위해 id를 사용하는 경우가 많은데 이때 인용 부호를 잘못 입력하여 데몬이 제대로 구동하지 않는 경우가 많다. 예를 들어 다음은 틀린 예이다.

#!/bin/sh
Q_UID='id -u qmaild'
Q_GID='id -g qmaild'

exec /usr/local/bin/softlimit -m 7340032 \
     /usr/local/bin/tcpserver -vHRl 0 -x /etc/tcp.smtp.cdb \
     -u $Q_UID -g $Q_GID 0 25 /var/qmail/bin/qmail-smtpd 2>&1

이 스크립트는 인용 부호를 잘못 사용하였다. 'id -u qmaild' 는 id -u qmaild 가 되어야 한다. 즉, 다음이 정확한 스크립트이다.

#!/bin/sh
Q_UID=`id -u qmaild`
Q_GID=`id -g qmaild`

exec /usr/local/bin/softlimit -m 7340032 \
     /usr/local/bin/tcpserver -vHRl 0 -x /etc/tcp.smtp.cdb \
     -u $Q_UID -g $Q_GID 0 25 /var/qmail/bin/qmail-smtpd 2>&1

또한 tcpserver에 사용되는 -l 옵션도 영문 L 의 소문자, 숫자 0 인것에 주의하라 (I나 O가 아니다).

1.12 외부로 부터 메일 수신이 안됩니다. #

외부로 부터 메일 수신이 안되고 있는 경우에는 다음을 확인해 봅니다.

1. qmail-smtpd가 제대로 동작하고 있는가?
2. 외부에서 해당 도메인의 DNS 설정(A/MX 레코드)가 제대로 되었는가?

해결이 불가능한 경우 질문/답변 게시판에 qmail-smtpd 구동 스크립트의 내용과 qmail-showctl 실행 결과를 수정 없이 올립니다.

1.13 vpopmail 가상 계정의 POP 인증이 안 됩니다. #

vpopmail 컴파일시 --enable-default-domain 옵션을 사용하지 않은 나머지 가상 도메인의 POP 계정은 클라이언트 설정시 계정 이름과 도메인 이름을 모두 사용해야 합니다. 즉, user@domain.org 와 같은 형식을 사용합니다.

1.14 glibc 2.3.1 이상에서 qmail 컴파일이 안 됩니다. #

glibc 2.3.1 이상에서는 qmail과 ucspi-tcp, daemontool 같은 관련 프로그램을 컴파일 하려면 다음에서 각각의 패치를 받아 패치후 컴파일 합니다.
http://qmail.org/moni.csi.hu/pub/glibc-2.3.1/
또는 http://qmail.kldp.org/src/patches/glibc-2.3.1/

1.15 릴레이가 허용되고 있지 않은데도 qmail-remote 프로세스가 많습니다. #

릴레이가 허용되지 않고 내부 사용자가 메일을 보내고 있지 않는데도
remote 프로세스가 많을 때는 대부분 바운스되는 메일들 입니다.
첫번째 시도해 볼 것은 double bounce를 참조 합니다.

qmail smtp는 기본적으로 envelope의 수신자 주소가 시스템에 존재하지 않아도
일단 큐에 넣었다가 배달이 실패하면 바운스 하도록 되어 있습니다.
이것은 메일러의 정상적인 프로세스 이며 큐에 넣기 전에 받아들이지 않으려면
패치를 해야 합니다. 다음 글타래를 참고 하십시요.
goodrcptto, realrcptto patch

[출처] qmail.kldp.org FAQ|작성자 린사랑

MSSQL 2008 각 버전별 비교

(neosky) — Mon, 01 Feb 2010 11:52:47 +0900

1. 코어 에디션

SQL Server 2008 Enterprise : 엔터프라이즈 온라인 트랜잭션 처리 및 데이터 웨어하우징(DW) 애플리케이션에 대한 높은 요구를 만족시켜주는 포괄적인 데이터 플랫폼입니다

SQL Server 2008 Standard : SQL Server 2008 Standard는 소규모 단위의 애플리케이션 운영을 위해 사용이 간편하고 용이한 관리성을 제공하는 완전한 데이터 관리 플랫폼입니다

2. 전문 에디션

SQL Server 2008 WorkGroup : 지점에서 운영할 수 있도록 안전한 원격 동기화 및 관리 기능을 제공해주는 안정적인 데이터 관리 및 리포팅 플랫폼입니다.

SQL Server 2008 Web : 귀하의 고객들에게 낮은 비용으로 고 가용성 기능을 갖춘 웹 응용프로그램 또는 인터넷 호스팅 솔루션을 제공하여 효율적인 웹 서비스 환경을 제공합니다.

SQL Server 2008 Developer

3. 프리 에디션

SQL Server 2008 Express : 무료 다운로드가 가능하며 Express는 데스크탑 및 작은 서버 애플리케이션을 학습하고 구축하거나 ISV에 의해 이를 재배포할 시 적합한 에디션입니다.

SQL Server 2008 Compact 3.5 : 무료 다운로드가 가능하며 모바일 장치, 데스크톱 및 웹 클라이언트를 위한 자립형 및 가끔씩 연결하는 (occasionally connected) 애플리케이션을 모두 Microsoft Windows 플랫폼에서 구축해보십시오.

Standard

중소기업용 전체 데이터 플랫폼

SQL Server Standard는 전체 데이터 관리 및 BI(business intelligence) 플랫폼으로 부서 애플리케이션을 실행하기 위한 최상의 사용편의성과 관리용이성을 제공합니다.

- 사용편의성
중소기업용 데이터베이스 솔루션에 대한 사용하기 쉬운 데이터베이스 플랫폼을 사용하므로 운영 및 개발 오버헤드가 감소됩니다.

- 관리용이성
직관적인 관리 도구 및 자동화된 관리를 사용하여 개별 애플리케이션을 효과적으로 관리합니다.

- 보고 및 분석
내장형 분석 및 보고 기술을 통해 통찰력을 제공하고 의사 결정을 강화합니다.

핵심 사용 시나리오

- 최상의 관리용이성과 사용편의성을 필요로 하는 부서 애플리케이션

- 중소기업용 OLTP(online transaction processing) 애플리케이션

- 기본 보고 및 분석을 필요로 하는 DSS(Decision Support System)

Express

SQL Server 2008 Express는 SQL Server의 무료판으로 데스크톱 및 소규모 서버 애플리케이션을 학습하고 구축하는데 이상적이며 ISV에서 재배포하는 경우에도 적합합니다. SQL Server Express에는 기존 또는 대화형 보고를 작성하고 전달하기 위한 서버 기반 플랫폼인 SQL Server 2005 Reporting Services 및 데이터베이스를 편리하게 관리하기 위한 그래픽 관리 도구인 SQL Server 2008 Management Studio Express와 같은 강력한 기능이 포함되어 있습니다.

- 강력함
SQL Server 데이터베이스 엔진의 보안, 안정성 및 확장성을 활용하는 고성능 애플리케이션을 개발합니다.

- 생산성
SQL Server Express와 Visual Studio 디자이너 및 SQL Server Management Studio를 긴밀하게 통합하여 애플리케이션을 신속하게 개발합니다.

- 유연성
네트워크에 연결하지 않고 중앙 데이터베이스에 자동으로 동기화되는 OCS(occasionally connected solution)를 개발합니다.

핵심 사용 시나리오

- 엔트리 레벨 및 학습 데이터베이스

- 고급 데스크톱 애플리케이션 구축

- ISV(Independent Software Vendor)에 대한 무료 재배포 권한

MSSQL 2005 Express 에디션의 제약조건

(neosky) — Mon, 01 Feb 2010 11:26:23 +0900

1. 들어가기 앞서…

--------------------------------------------------------------------------------
Microsoft SQL Server 2005 Express 에디션! (이하 MSSQL 2005 Express) Microsoft 제품군에서 찾아보기 힘든 아주 바람직하고 착한(?) 라이센스를 가지고 있는 제품이다. 모든 최대한 잘게 쪼개고 그럴싸하게 모아서 새로운 에디션을 하나 더 만들어 팔길 좋아하는 Microsoft에서 무슨 바람이 불어 MSSQL 2005 Express 에디션을 발표했는지 지금 생각해봐도 의문점 투성이다.
아무튼 제작사 측에서 어마어마한 MSSQL 라이센스 비용을 절감할 수 있는 절호의 기회를 제공해 주었으니 사용자 입장에서는 잘 써주는 게 인지상정 아니겠는가. 물론, 발표한지 꽤나 시간이 흐른 제품이기 때문에 이미 여러모로 잘 사용하고 계신 분들이 많을 거라 추정된다.

본 글에서는 MSSQL 2005 Express 에디션의 제약 조건에 대해서 살펴볼까 한다.

2-1. 우선 MS에서 공식적으로 제공하고 있는 에디션 별 제약 조건부터…

--------------------------------------------------------------------------------
아래 링크 주소를 따라가 보면 Microsoft 측에서 공식적으로 제공하고 있는 Microsoft SQL Server 2005 에디션 별 제약 조건을 한눈에 파악할 수 있다. 우선 이것부터 한 번 훑어보는게 좋지 않을까? 물론 영어의 압박이 좀 있기 하지만, 이해 자체에 큰 문제가 발생할 만큼 어렵지 않다.
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx

2-2. 전체텍스트검색 불가?!

--------------------------------------------------------------------------------
전체텍스트검색’은 내가 알기로 Windows NT 4.0 때 인덱스 서비스(기억이 가물가물…)라는 이름으로 처음 사용자들에게 공개된 것으로 알고 있다. 그만큼 도입된 지 꽤 오래된 기능이라 할 수 있다.
‘전체텍스트검색’의 용도를 간단히 예를 들어 설명해 보자면 다음과 같다.

‘A’라는 게시판에 본문 검색 기능이 탑재되어 있다. 그리고 사용자가 ‘윈도우’라는 단어로 본문 검색을 시도했다면 아래와 같거나 또는 유사한 쿼리가 SQL 서버에 결과값을 요청하게 될 것이다.

SELECT * FROM aboard WHERE contents LIKE ‘%윈도우%’ ORDER BY idx DESC

DB 양이 얼마 되지 않는다면 처리하는데 큰 문제가 없겠지만, 글 수가 몇 십, 백만 건 또는 그 이상이라면 분명 SQL 서버는 큰 부하를 겪게 될 것이다. ‘aboard’ 테이블의 ‘contents’ 컬럼에서 ‘윈도우’라는 단어로 전체 검색을 해야 하기 때문입니다.

‘전체텍스트검색’은 바로 이런 부분들을 효율적으로 관리하기 위해 마련된 기능이라 할 수 있다. 쉽게 정리하자면 특정 테이블의 특정 컬럼에서 미리 단어들를 추출 및 정리해 놓았다가 위의 예 처럼 본문 검색 기능 등에 적용하여 유용하게 사용하는 것이다.

물론 MS-SQL 엔진 자체 내에도 인덱스라는 기능이 있다. 하지만, ‘전체텍스트검색’과는 성질이 다소 다르다고 할 수 있다. ‘전체텍스트검색’은 엄연히 MS-SQL 엔진 범주에 포함된 부분이지만, ‘전체텍스트검색’의 데이터라 할 수 있는 카탈로그와 자체 인덱스의 관리는 MS-SQL 엔진이 아닌 윈도우즈 파일시스템을 사용하고 있기 때문이다. 그리고 SQL 인덱스와는 달리 ‘전체텍스트검색’의 인덱스는 수동으로 갱신해 주어야 한다. 이때 발생하는 엄청난 I/O 부하는 여전히 해결해야 할 난제로 알고 있다.

아무튼 기본적으로 MSSQL 2005 Express 에디션은 '전체텍스트검색'을 지원하지 않는다.

하지만!!!

'Microsoft SQL Server 2005 Express Edition with Advanced Services SP2' 이녀석을 설치하면 '전체텍스트검색' 기능을 사용할 수 있다. '전체텍스트검색'이 일반적으로 자주 사용되는 기능은 아니지만 이왕이면 새옹지마라고…

다운로드 경로는 아래 링크 주소를 참고하시기 바란다.

http://www.microsoft.com/downloads/details.aspx?FamilyID=5b5528b9-13e1-4db9-a3fc-82116d598c3d&DisplayLang=ko

2-3. 다중 프로세서 지원 불가

--------------------------------------------------------------------------------
다중 프로세서란 쿼드코어나 듀얼코어 CPU처럼 CPU 하나에 여러 개의 코어가 탑재된 것을 의미하는 것이 아니라 말 그대로 물리적으로 CPU가 2개 이상 장착되어 있는 것을 의미한다.
MSSQL 2005 Express 에디션은 다중 프로세서를 지원하지 않는다. 물론, 다중 프로세서가 장착된 서버에서 설치 또는 실행 자체가 되지 않는 것은 아니다.

2-4. 할당 메모리 1GB로 제한

--------------------------------------------------------------------------------
MSSQL 2005 Express 에디션은 SQL Server에 할당할 수 있는 메모리 용량이 1GB로 제한되어 있다.

2-5. 데이터베이스 당 최대 용량 4GB로 제한

--------------------------------------------------------------------------------
MSSQL 2005 Express 에디션에서는 1개의 데이터베이스가 사용할 수 있는 최대 용량이 4GB로 제한되어 있다.
유의할 사항은 순수 DATA 용량만을 가지고 계산하는 것이기 때문에 4GB 용량 제한에는 트랜젝션로그 용량은 포함되지 않는다. 아울러 데이터베이스 개수에는 별도의 제한 사항이 없다.

2-6. DTS 및 SSIS 사용 불가

--------------------------------------------------------------------------------
MSSQL 2005에서 가장 주목 받는 부분 중 하나가 바로 MSSQL 2000보다 향상된 데이터 내보내기/가져오기(DTS) 기능이다. 아쉽게도 현재 MSSQL 2005 Express 에디션에서는 이 DTS 기능을 비롯한 SSIS 자체를 공식적으로 지원하지 않는다.
SSIS란, SQL Server Integration Services의 약자로써 쉽게 말하자면 DTS의 강화판이라 할 수 있다. MSSQL 2000에서도 타 기종 간의 데이타 이전이나 외부 SQL 서버에 보존된 데이타 가져오기 또는 반대로 데이터 내보내기 기능등은 어느 정도 수준까지 지원했으나 SSIS에서는 이 기능을 좀 더 강화하여 따로 독립된 서비스로 분류하고, 플로우(Flow) 자체를 엔진화 했다.

이런 좋은 기능을 MSSQL 2005 Express 에디션에서는 공식적으로 지원하지 않는다는 것이 매우 안타까울 다름이다. 하지만, 그보다 서버 이전이나 차후에 발생할 수 있는 상황들을 고려해 봤을 때 DTS 기능을 사용할 수 없다는 것은 참으로 난감한 일이 아닐 수 없다.

일단, 'Microsoft SQL Server 2005 Express Edition Toolkit SP2'를 설치하면 DTS 기능을 사용할 수 있다. 다운로드 경로는 아래 링크 주소를 참고하시기 바란다.

http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ad606a-0960-4efd-8bd7-b21370c7be2b&DisplayLang=ko

설치가 완료되었다면 '설치폴더\90\DTS\Binn\DTSWizard.exe'파일을 수동으로 실행시켜 필요시마다 DTS 기능을 사용할 수 있다.

출처: http://nice19.net/blog/index.php/archives/105

추가 각 에디션별 차이점 비교표 (간단한..)

http://www.microsoft.com/sqlserver/2008/en/us/editions.aspx

성남시외버스터미널 시간표 (2009. 12. 09 현재)

(neosky) — Wed, 27 Jan 2010 02:42:13 +0900

※청주,대전,제천,강릉,속초,춘천,상주,구미,포항,울산,안동,군산,강진,광양,부안,익산,정읍,순천,목포,고한,김해노선은 좌석제 일주일전 현장 예매가능 (9:00~22:00)

※화물은 현장에 직접오셔서 기사분께 문의하세요~~!! (구미,경주,울산,포항,순천,안동,청주,평택,오산,군산,진천방면화물은 031)725-1483으로 문의하세요!!)

Port 용도 검색 사이트

(neosky) — Fri, 15 Jan 2010 17:57:58 +0900

http://www.speedguide.net/port.php?port=

port= 뒷부분에 알고자하는 Port 를 숫자로 넣으면 된다.

ping 결과를 file 로 저장하고자 할때 'fping'

(neosky) — Wed, 13 Jan 2010 23:24:11 +0900

첨부된 파일을 받고, 설치할 필요는 없다. fping 이 위치한 곳에서 다음과 같이 명령을 내려주게 되면

fping 192.168.1.1 -T -c >> ping.txt

다음과 같이 time stamp 와 함께 ping test 내역이 파일에 기록된다.

(c) Wouter Dhondt (http://www.kwakkelflap.com)

Pinging 192.168.1.1 with 32 bytes of data every 1000 ms:

18:06:18 : Reply[1] from 192.168.1.1: bytes=32 time=0.7 ms TTL=61
18:06:19 : Reply[2] from 192.168.1.1: bytes=32 time=1.3 ms TTL=61
18:06:20 : Reply[3] from 192.168.1.1: bytes=32 time=1.8 ms TTL=61
18:06:21 : Reply[4] from 192.168.1.1: bytes=32 time=0.5 ms TTL=61
18:06:22 : Reply[5] from 192.168.1.1: bytes=32 time=0.7 ms TTL=61
18:06:23 : Reply[6] from 192.168.1.1: bytes=32 time=0.7 ms TTL=61
18:06:24 : Reply[7] from 192.168.1.1: bytes=32 time=0.5 ms TTL=61

fping222.zip