'Linux'에 해당되는 글 112건

2006/09/08 how to wget

2006/09/08 Database 연동 - DBD/DBI 설치하기

2006/09/08 DBI, DBD Perl 모듈 설치방법

2006/09/08 scp 사용법

2006/09/08 LINUX = SCP --원격 파일 전송 (1)

2006/09/08 rpm 패키지 뽑아내기

2006/09/08 RPM이란?

2006/09/08 How to 'chroot' an Apache tree with Linux and Solaris

2006/09/08 [Redhat] 호스트명(hostname) 변경하기

2006/09/08 로드밸런싱

Linux 2006/09/08 14:17

how to wget

블로그 > F.o.r.c.e.♣.W.i.t.h.☞.M.e

http://blog.naver.com/xxfinger/100006339285

[펌]가제트 한글판???

브라우저없이 다운로드하기

By Adrian J Chung

한글번역 전정호

이 글은 한글번역판입니다. 원문은 여기에서 볼 수 있습니다.

늦은 속도로 큰 파일을 받기위해 웹브라우저를 몇시간 혹은 몇일 동안 켜둔 적이 있는가? 한 웹페이지에 링크된 파일 40개를 다운로드하기위해 지루하게 하나하나 클릭한 적이 있는가? 다운로드가 끝나기도 전에 브라우저가 죽으면? GNU/Linux에는 브라우저없이 배경에서 다운로드하는 여러 도구가 있다. 이 도구를 사용하면 (다운로드가 끝나기 전에) 로그아웃할 수도 있고 끊어진 다운로드를 이을 수도 있으며 심지어 네트웍 사용량이 적을 때 다운받도록 할 수도 있다.

대화적인 방법이 불편할 때

웹브라우저는 웹을 클릭하여 몇초안에 내용을 보기 위한 (즉, 대화적인) 도구이다. 그러나 아무리 빨라도 몇초만에 다운로드할 수 없는 파일들이 많다. 예를 들어 GNU/Linux CD-ROM 배포본을 저장하는 ISO 이미지가 있다. 어떤 잘못 프로그램된 웹브라우저는 메모리를 낭비하고 갑자기 죽어서 오랜동안 사용하기에 적당치않다. 많은 브라우저가 있지만 여러 파일을 한번에 쉽게 다운로드할 수 있는 다중세션이나 (그래픽 편집 프로그램에서 영역을 선택하는 것과 같은) 선택기 기능이 있는 프라우저는 없다. 또한 파일을 모두 다운로드하기 전에 로그아웃할 수도 없다. 결정적으로 사무실에서 다운로드하면 대역폭을 공유하는 동료들을 화나게한다.

큰 파일을 다운받는데 적당한 도구들이 있다. 이 글은 GNU/Linux에 포함된 lynx, wget, at, crontab으로 파일 전송 문제를 해결하는 방법을 설명한다. 스크립트도 조금 사용할 것이므로, bash에 대해 조금 알면 도움이 될 것이다.

`wget 도구`

대부분 배포본은 다운로드 도구인 wget을 포함한다.

 bash$ wget http://place.your.url/here

이 프로그램은 FTP나, 최근 수정된 파일 혹은 전체 웹사이트의 미러를 처리할 수 있다. (주의하지 않으면 전체 웹사이트 외에 링크된 사이트들도 다운로드할 것이다.) 웹사이트 미러(-m)는 다음과 같이 한다.

 bash$ wget -m http://target.web.site/subdirectory

이 프로그램이 서버에 부하를 걸 수 있기 때문에 미러할 때는 "robots.txt" 규칙을 준수한다. 이 프로그램에는 정확히 어떤 파일을 미러할지, 따라갈 링크의 종류와 다운로드할 파일종류를 조정하는 옵션이 있다. 예를 들어 상대적인 링크만(-L)을 따라가며, GIF 이미지는 다운로드하지 않는다면(--reject=gif),

 bash$ wget -m -L --reject=gif http://target.web.site/subdirectory

또한 wget는 다 받지않고 중단된 다운로드를 이을 수 있다. ("-c" 옵션) 단, 서버가 이어받기를 지원해야 한다.

 bash$ wget -c http://the.url.of/incomplete/file

이어받기나 미러를 결합하여 (여러번 시도하여) 많은 파일이 있는 사이트를 완전히 미러할 수 있다. 어떻게 자동화하는지는 아래서 설명한다.

내 사무실과 같이 다운로드가 자주 끊어진다면 여러번 시도하도록 할 수 있다.

 bash$ wget -t 5 http://place.your.url/here

위의 예는 5번 시도후에 포기한다. "-t inf"를 사용하면 포기하지 않는다.

프록시 방화벽을 사용한다면 어떻게하나? 환경변수 (대문자가 아니라 소문자로) http_proxy나 .wgetrc 설정파일로 사용할 프록시를 설정할 수 있다. 프록시된 연결의 문제점은 이어받기가 자주 실패할 수 있다는 점이다. 프록시 연결이 중단되면 프록시 서버는 파일의 일부만을 (전부 받았다고 생가하여) 캐쉬한다. 이어받기를 하기 위해 "wget -c"를 사용하면 프록시는 캐쉬를 보고 파일을 이미 다 받았다고 잘못된 보고를 한다. 특별한 헤더를 사용하여 대부분의 프록시가 캐쉬를 하지 않게 할 수 있다.

 bash$ wget -c --header="Pragma: no-cache" http://place.your.url/here

"--header" 옵션으로 헤더를 추가하여 웹서버나 프록시의 행동을 수정할 수 있다. 어떤 사이트는 외부에서 링크된 파일을 다운로드할 수 없게 하고, 같은 사이트에서 링크된 파일만 다운로드할 수 있게 하는 경우가 있다. 이 경우 "Referer:" 헤더를 사용하여 해결할 수 있다.

 bash$ wget --header="Referer: http://coming.from.this/page" http://surfing.to.this/page

어떤 나쁜 웹사이트는 특정 브라우저에서만 접속할 수 있다. 이 경우 "User-Agent:" 헤더를 사용하여 해결할 수 있다.

 bash$ wget --header="User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)" http://msie.only.url/here

(주의: 위의 팁은 내용의 라이센스를 어기는 것으로 고려될 수 있으며 이를 불법으로 규정하는 나쁜 법들이 있다. 지역마다 다르니 확인해봐라.)

언제 다운로드하지? (`at`)

스트리밍 동영상이 느려지는 것을 좋아하지 않는 동료와 연결을 공유하는 사무실에서 큰 파일을 다운로드한다면 사람들이 사용하지 않는 시간에 다운로드하는 것을 고려해볼 수 있다. 모두가 떠난 후에도 사무실을 지키거나 저녁식사후 원격접속할 필요는 없다. 작업 스케줄러 at을 사용하면 된다.

bash$ at 2300 warning: commands will be executed using /bin/sh at> wget http://place.your.url/here at> press Ctrl-D

이제 오루 11시에(2300) 다운로드가 시작된다. 스케줄러 데몬인 atd가 실행되고 있는지 확인해라.

다운로드가 몇일이 걸린다면?

여러 큰 파일을 다운로드받아야 하고 네트웍이 비둘기 전령사 수준이라면, 아침에 사무실에 도착할때까지 다운로드가 안끝날 수 있다. 좋은 이웃이 되기위해 작업을 중단하고 다른 at 작업으로 다받을 때까지 몇일이고 이어받기를 한다. (이번에는 "wget -c") 이 과정을 crontab으로 자동화할 수 있다. 다음 내용을 포함하는 "crontab.txt"란 파일을 만든다.

0 23 * * 1-5 wget -c -N http://place.your.url/here 0 6 * * 1-5 killall wget

이는 특정 시간 간격으로 작업을 지시하는 crontab 파일이다. 처음 5 항목은 언제 명령어를 실행할지를 지시하고, 나머지는 무엇을 실행할지를 지시한다. 처음 두 항목은 하루중 시간을 지칭한다. 그래서 wget은 오후 11시 0분, killall wget은 오전 6시 0분에 실행된다. 세번째와 네번째 항목인 *은 어떤 달의 어떤 날도 가능하다는 뜻이다. 다섯번째 항목은 작업을 수행할 요일을 지시한다. "1-5"는 월요일에서 토요일까지를 의미한다.

그래서 주중의 오후 11시에 다운로드를 시작하고, 오전 6시에 중단한다. 이제 다음 명령어를 실행하여 스케줄에 따라 명령이 실행되게 하자.

 bash$ crontab crontab.txt

wget의 "-N" 옵션은 다운받기 전에 대상 파일의 수정 시간을 검사하여, 파일을 다받았다면 다운로드를 하지 않는다. 그래서 이 옵션은 아무 문제없이 사용할 수 있다. "crontab -r"은 스케줄을 제거한다. 나는 이 방법으로 많은 ISO 파일을 여럿이 사용하는 전화선으로 받았다.

동적으로 생성한 웹페이지

어떤 웹페이지는 내용이 하루에도 여러번 바뀌기 때문에 요청할 때마다 생성된다. 대상이 기술적으로 파일이 아니라면 (즉 그때그때 생성되는 내용이라면), 파일 길이가 없고 이어받기는 의미가 없다. "-c" 옵션은 제대로 동작하지 않는다. 예를 들어 Linux Weekend News에서는 PHP로 페이지를 만든다.

 bash$ wget http://lwn.net/bigpage.php3

다운로드가 중단되어 이어받기를 하면 처음부터 다시 받는다. 나의 경우 사무실의 연결이 자주 바빠지기 때문에 동적으로 생성된 HTML 파일이 다 받아졌는지 확인하는 스크립트를 작성했다.

#!/bin/bash # 파일이 없으면 만든다 touch bigpage.php3 \

# 다 받았는지 검사 while ! grep -qi '</html>' bigpage.php3 do rm -f bigpage.php3 \

# LWN을 한 페이지로 다운로드 wget http://lwn.net/bigpage.php3 done

위의 bash 스크립트는 문서에서 HTML 파일 끝을 나타내는 "</html>"이 발견될 때까지 문서를 다운로드한다.

SSL과 쿠키(cookie)

"https://"로 시작하는 URL은 SSL(Secure Sockets Layer, 전송을 암호화한다)을 통해 접근한다. 이 경우 curl이라는 다른 다운로드 도구를 사용할 수 있다.

어떤 웹사이트는 내용을 전송하기 전에 쿠기를 전송한다. 이 경우 웹브라우저의 쿠키파일에서 적절한 정보를 "Cookie:" 헤더에 추가해야 한다. lynx와 Mozilla 쿠키파일 형식으로는, (이미 브라우저로 이 사이트에 등록한 경우)

 bash$ cookie=$( grep nytimes ~/.lynx_cookies |awk '{printf("%s=%s;",$6,$7)}' )

으로 http://www.nytimes.com에서 다운로드할 때 사용할 쿠키를 얻을 수 있다. w3m의 쿠키파일은 형식이 조금 다르다.

 bash$ cookie=$( grep nytimes ~/.w3m/cookie |awk '{printf("%s=%s;",$2,$3)}' )

그런후 다운로드를 한다.

 bash$ wget --header="Cookie: $cookie" http://www.nytimes.com/reuters/technology/tech-tech-supercomput.html

curl을 사용한다면,

 bash$ curl -v -b $cookie -o supercomp.html http://www.nytimes.com/reuters/technology/tech-tech-supercomput.html

URL 목록 만들기

아직까지 한 파일 혹은 전체 웹사이트를 다운로드했다. 가끔 전체 사이트를 미러하지는 않지만 많은 파일을 다운로드해야 할 때가 있다. 예를 들어 100위까지 순서대로 음악파일을 포함하는 사이트에서 20위까지만 받을 때가 있다. 이 경우 "--accept"나 "--reject" 옵션은 파일들의 확장자가 동일하므로 사용할 수 없다. 대신 "lynx -dump"를 실행한다.

 bash$ lynx -dump ftp://ftp.ssc.com/pub/lg/ |grep 'gz$' |tail -10 |awk '{print $2}' > urllist.txt

lynx의 출력을 GNU 문자처리 도구로 처리한다. 위의 예에서는 "gz"로 끝나는 URL을 뽑아서 마지막 10개만 저장한다. 간단한 bash 스크립트 명령어로 이 파일에 기록된 URL을 자동으로 다운로드할 수 있다.

bash$ for x in $(cat urllist.txt) > do > wget $x > done

이제 우리는 Linux Gazette에서 최근 열개를 다운로드했다.

대역폭을 최대로

당신이 넢은 대역폭을 사용할 수 있는 선택받은 소수라면 다운로드 속도는 웹서버 부하에 결정된다. 그렇다면 파일 전송을 "빠르게하는" 편법이 있다. 먼저 curl과, 같은 파일을 미러하는 여러 웹사이트가 필요하다. 예를 들어 다음 3 곳에서 Mandrake 8.0 ISO를 다운받는다고 가정하자.

url1=http://ftp.eecs.umich.edu/pub/linux/mandrake/iso/Mandrake80-inst.iso \

url2=http://ftp.rpmfind.net/linux/Mandrake/iso/Mandrake80-inst.iso \

url3=http://ftp.wayne.edu/linux/mandrake/iso/Mandrake80-inst.iso \

파일 크기는 677281792다. curl의 "--range" 옵션을 이용하여 동시에 다운로드한다.

bash$ curl -r 0-199999999 -o mdk-iso.part1 $url1 & \

bash$ curl -r 200000000-399999999 -o mdk-iso.part2 $url2 & \

bash$ curl -r 400000000- -o mdk-iso.part3 $url3 & \

그러면 다른 서버에서 파일의 다른 부분을 다운로드를 하는 세 배경 프로세스가 생긴다. "-r" 옵션은 다운로드할 파일의 범위를 (바이트로) 지정한다. 다 마쳤으면 세 부분을 cat으로 간단히 합칠 수 있다. cat mdk-iso.part? > mdk-80.iso (CD-R을 굽기전에 md5를 확인하길 권한다.) 서로 다른 창에서 "--verbose" 옵션을 사용하여 curl을 실행하면 전송 과정을 보여준다.

결론

다운로드를 위해 비대화적인 방법을 사용하는 것을 두려워하지 마라. 웹 디자이너가 사이트를 대화적으로 서핑하도록 노력하였더라도 다운로드를 자동화하는 도구는 항상 있다.

Adrian J Chung

(케리비안해의) 트리니다드토바고의 West Indies 대학에서 학부생을 가르키지 않을 때면 Andrian은 웹메일 다운로드를 자동화하는 스크립트를 작성하고 직접 만든 그래픽 렌더러와 자료 시각화 라이브러리를 사용하여 다양한 스크립트 환경을 경험한다.

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:16

Database 연동 - DBD/DBI 설치하기

블로그 > 난 다랑어야 ~♡ ∑⊙■■■◀

http://blog.naver.com/cs7127/40013539902

먼저 그동안 일에 때문에 강좌 및 개인적으로 공부를 소홀히 한점에 대하여 반성하면서 제 스스로를 반성하면서 약속드립니다.

그럼 .. 본격적으로 DBD/DBI Module 설치하는 방법에 대하여 소개하겠습니다.

음.. 한가지 아픔이 있다면 PHP라는 언어이지요. 요즘 유행처럼 PHP를 사용하고 있지요. 그러므로써 Perl 언어의 자리가.. 흐흐흐..

본인도 PHP를 공부했지만 아직도 perl를 좋와합니다.

이유는 Perl는 정말로 프로그래머라면 한번씩 공부해 봐야 할 언어라고 생각하고 그곳에서 많은 것을 배울수 있다고 생각하기 때문입니다.

펄에서 DB Connection 하는 원리에 대하여는 간단하게 이전 강좌에서 소개를 했습니다.

지금 부터는 어떻게 System에 해당 Module를 설치하느냐 이지요...

Linux / Unix 시스템에서 해당 Module를 설치하는 것은 그렇게 간단한 문제라고만 볼수 없습니다. 거기에는 많은 변수가 존재하기에...

쉽게 설치가 될수 있지만 아니면 좀 고생을 해야 한다는 것이지요.

일반적으로 Cpan에서 배포하는 Module에는 Makefile.PL 이 있습니다. 이 Makefile.PL에 대하여는 MakefileMaker Module에 대하여 소개할 시간이

있을 때 소개하지요.

간단하게 소개하면

> perl Makefile.PL
> make
> make test
> make install

의 과정으로 설치합니다.

Makefile.PL 은 Makefile를 만들어 주지요. vi 로 Makefile를 열어 보면 무슨 소리인지 ~~ 라고 생각할 것입니다.....

Makefile 에 대하여는 Make Util에 대한 이해가 있다면 쉽게 알수 있을 것입니다. 잘 모르시는 분은 그런 것이 있구나 하고 생각하면 됩니다.

설치 Module은 대부분은 Perl 경로중에서 root 권한으로만 접근이 가능한곳을 수정및 추가 하기에 root 권한으로 설치하셔야 합니다

설치순서는 DBI -> DBD 설치 입니다.

DBI 설치하기

해당 자료는 ftp://ftp.nuri.net/pub/CPAN/modules/by-module/DBI 에 가서 다운 받으시면 됩니다.

DBI는 사용 DB와 상관없이 그냥 다운 받아 설치하면 됩니다.

> gunzip DBI-1-13.tar.gz
> tar xvf DBI-1-13.tar

하시면 해당 Directory가 생성되지요..

> cd DBI-1-13

하시고 ls 해 보시면 위에서 말한 Makefile.PL를 볼수 있을 것입니다.

simfms#/usr/src/DBI-1.13> ls
Changes DBI.xs Makefile.PL README dbiproxy pm_to_blib
DBI.bs DBIXS.h Perl.c ToDo dbiproxy.PL t
DBI.c Driver.xst Perl.o blib dbish test.pl
DBI.o MANIFEST Perl.xs dbd_xsh.h dbish.PL
DBI.pm Makefile Perl.xsi dbi_sql.h lib

> perl Makefile.PL
> make
> make test
> make install

perldoc DBI 로 확인하시면 되지요. 간혼 perldoc 는

perl 이 설치되어 있는 해당 디렉토리에 같이 있지요.. 보통은 usr/local/bin 에 설치되는 것으로 알고 있지만 system마다 다르니..

95%는 모두 설치되는 것으로 알고 있고 간혹 System들이 거부하는 경우가 있지만 역시 노력으로 극복할수 있으니 걱정은 금물....

설치된 프로그램은 모두 perl5의 lib 디렉토리밑으로 설치가 되어 들어가지요...

DBD Module 설치

DBD Module은 사용 DB 마다 모두 다르지요. Oracle,Sysbase,Mysql 등

그러나 설치방법은 모두 동일 여기서는 Oracle 가지고 설명하지요.

ftp://ftp.nuri.net/pub/CPAN/modules/by-module/DBD/ 에 가시면 거이 대부분에 대한 DB의 Module이 있습니다.

> gunzip DBD-Oracle-xx.tar.gz
> tar xvf DBD-Oracle-xx.tar.gz

여기서 ls 해 보면

imfms#/usr/src/DBD-Oracle-1.03> ls
Changes Oracle.pm README.longs hints oraperl.ph
MANIFEST Oracle.xs README.sec oci.def pm_to_blib
Makefile Oracle.xsi README.win32 oci7.c sqlnet.log
Makefile.PL Oraperl.pm README.wingcc oci7.o t
Oracle.bs README Todo oci8.c test.pl
Oracle.c README.clients blib oci8.o
Oracle.ex README.explain dbdimp.c ocitrace.h
Oracle.h README.help dbdimp.h ora_explain
Oracle.o README.login dbdimp.o ora_explain.PL

가장 중요한 것은 Readme 파일을 잘 읽어 보시라는 것이지요. 그곳에 답이 모두 있으니까요.....

> perl Makefile.PL
> make
> make testl
> make install

뭐 잘못 설치 되었다고 걱정할 필요는 하나도 없구요. make clean 하시면 되고 하니면 해당 directory 가서 파일을 지우시면 됩니다.

저 같은 경우에도 HP Unix에서 설치가 잘 되지 않아 좀 고생했지요. 이상한 Error에 대하여는 저의 경험상 System 관리자 및 System를 팔아 먹은

놈들에게 전화하면 되지요.....

다음 시간에는 잘 설치에 이어서 사용법에 대하여 이야기 하지요...

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:16

DBI, DBD Perl 모듈 설치방법

블로그 > loves0508님의 블로그

http://blog.naver.com/loves0508/9859402

제목 [리눅스] DBI, DBD Perl 모듈 설치방법

내용 1. Msql-Mysql-modules-1.2216.tar.gz 설치
2. DBI-1.35 설치
3. DBD-mysql-2.1026 설치

* 주의
mysql.sock 참조를 /var/lib/mysql/mysql.sock 에서 할경우에는
/tmp.sock 를 /var/lib/mysql/mysql.sock에 sybolic 링크한다.

이렇게 데몬을 띄울수도 있지만 다른 mysql 접속 부분에 오류가 발생할수 있다.
* /usr/local/mysql/bin/safe_mysqld --socket=/var/lib/mysql/mysql.sock &

1. root로 로그인해서 설치해주세요!
db모듈이 제대로 설치되었는지
perl -e "use DBI"
perl -e "use DBD"

실행해서 아무메세지도 안나오면 제대로 설치된것입니다...
하지만 그렇다고 안심하면 안됩니다..
어떨때는 메세지 안나오는데..모듈이 하나 빠져있는것이 있거든요...
이때 확인방법은

/usr/lib/perl5/site_perl/5.005/i386-linux
디렉토리로 이동해서 디렉토리 DBD DBI Mysql과 DBI.pm Mysql.pm 파일
이 있나 확인해보세요..하나라도 없으면 db모듈을 재설치 해줍니다.

일단, 설치 스크립트로 인해 잘 못 설치 되었던 모듈들을
삭제 합니다.
/usr/lib/perl5/site-perl/5.005/i386-linux/
의 경로에 가시면
DBI, DBD 등이 있는데 이것들을 지우시면 됩니다.
rm -rf DBI
rm -rf DBD
rm -rf DBI.pm
그리고 cd Auto 하셔서 그안에 있는 DBI도 삭제합니다.

* mysql이 실행중이어야 합니다

설치문
1. DBI
cd DBI-*.**
perl Makefile.PL
make
make install

2. DBD
cd DBD-*.**
perl Makefile.PL
make
make install

3. Msql-Mysql-modules_1.****
cd Msql-Mysql-modules_1.**** 에 가서(mysql이 동작중이어야 합니다.)

perl Makefile.PL
make

mysql만 설치되있으면 1번선택하고 엔터

perl + mysql 연동은 mysql을 소스로 설치하던, rpm으로 설치하던 상관이 없습니다.

다만 DBI를 설치할때 mysql의 설치 경로를 묻는 부분이 나타 납니다.
이때,

* mysql을 소스로 설치 하셨을 경우

예를 들어 mysql 설치된 경로가 /usr/local/mysql 이라면 /usr/local/mysql 로 지정을 해 주시면 됩니다.

* mysql을 rpm 설치시

자동으로 인식하기 때문에 그냥 enter 만 입력하셔도 됩니다.

그 다음부터는 부담없이 enter key를 치세요!

* root계정의 정보를 질문하면 응해준다.

make
make test
make install

확인

make test 할때 이런 에러면...상관없습니다..
Undefined subroutine &Test::Harness::WCOREDUMP called at /usr/lib/perl5/5.00503/Test/Harness.pm line 288.
make[1]: *** [test_dynamic] Error 10
make[1]: Leaving directory `/usr/local/src/Msql-Mysql-modules-1.2215/mysql'
make: *** [test] Error 2

그리고 잘 설치가 되었는지 브라우져에서도 실행시켜 보고,
perl -e "use DBI" , perl -e "use DBD"로 확인해 봅니다.

[ root@localhost Msql-Mysql-modules-1.2216]# perl -e "use DBI";
[ root@localhost Msql-Mysql-modules-1.2216]# perl -e "use DBD";
Can't locate DBD.pm in @INC (@INC contains: /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

만일 위의 내용이 나오면 성공입니다.

에러가 마음에 안드시면 /usr/lib/perl5/site_perl/5.6.0/i386-linux/DBI/DBD.pm파일을
/usr/lib/perl5/site_perl/5.6.0/i386-linux/에 카피하시면 됩니다.

cp /usr/lib/perl5/site_perl/5.6.0/i386-linux/DBI/DBD.pm /usr/lib/perl5/site_perl/5.6.0/i386-linux/

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:15

scp 사용법

블로그 > 시작..

http://blog.naver.com/iuwe1126/60013251653

scp 사용법
scp는 자신의 컴퓨터에서 원격의 컴퓨터로 또는 원격의 컴퓨터에서 자신의 컴퓨터로 간단하게
파일을 전송할 수 있는 프로그램이다.
다음은 현재 디렉토리에 있는 sshd.txt 라는 파일을 IP가 192.168.1.154 인 컴퓨터에 root 라는 계정으로
접속하여 /usr/local/src/ 디렉토리 밑에 복사해 넣는 명령이다.

[root@in4nux root]# scp ./sshd.txt root@192.168.1.154:/usr/local/src/

다음은 IP가 192.168.1.154 인 컴퓨터에 root 라는 계정으로 접속하여 /usr/local/src/ 디렉토리 밑에 있는
sshd.txt 라는 이름의 파일을 자신의 컴퓨터로 현재 위치한 디렉토리에 복사하는 명령이다.

[root@in4nux root]# scp root@192.168.1.154:/usr/local/src/sshd.txt ./

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:15

LINUX = SCP --원격 파일 전송

카페 > LINUX - 관련 JOB / 맥슬님

http://cafe.naver.com/passwd/5

...리눅스를 좀 더 재미있게!

암호없이 scp
By Dave Sirof

한글번역 전정호

이 글은 한글번역판입니다. 원문은 여기에서 볼 수 있습니다.

암호없이 scp

이 글은 암호없이 scp를 사용하는 방법을 설명하고, 두 근사한 스크립트를 소개한다. 한 스크립트는 파일을 네트웍으로 연결된 여러 리눅스 컴퓨터에 복사하고, 다른 스크립트는 리눅스 컴퓨터를 쉽게 백업할 수 있다.

리눅스 시스템 관리자는 자주 컴퓨터간에 파일을 복사하거나 파일을 여러 컴퓨터로 전송한다. ftp를 사용해도 되지만, scp를 사용하면 많은 이점이 있다. ftp는 LAN/WAN에 내용(심지어 암호도)을 그대로 전송하지만, scp는 암호화하여 전송하기때문에 ftp보다 안전하다.

scp의 장점은 쉽게 스크립트에서 사용할 수 있는 점이다. 파일을 리눅스 컴퓨터 100대로 복사한다고 가정하다. 직접 100번 복사 명령어를 실행하는 것보다 스크립트를 작성하고 싶을 것이다. 스크립트에서 ftp를 사용하면 로그인할때마다 암호를 물어보기때문에 힘들다 (역주; netrc 파일을 사용하여 암호를 자동으로 입력하게 만들 수 있지만 보안상 위험하다). 대신 scp를 사용하는 경우 원격 리눅스 컴퓨터가 암호를 물어보지 않도록 설정할 수 있다. 믿거나 말거나 이 방법은 ftp보다 훨씬 더 안전하다!

scp의 기본 문법은 다음과 같다. 현재 컴퓨터에 있는 'abc.tgz' 파일을 'bozo'라는 원격컴퓨터의 /tmp 디렉토리로 복사하려면:

scp abc.tgz root@bozo:/tmp

그러나 이 경우 bozo의 root 암호를 물어본다. 암호를 물어본다면 스크립트에서 쉽게 사용할 수 없다. 해결책은 다음과 같다 (한번만 해주면 "암호없이" 무제한 scp로 복사할 수 있다):

1. 나중에 scp를 사용하여 파일을 복사할 사용자를 결정한다. 물론 root가 가장 강력하고, 난 개인적으로 root를 사용한다. 여기서 root를 사용할때 발생할 수 있는 보안상 문제점을 강의할 생각은 없다. 내가 지금 무슨 말을 하는지 모르겠다면 root가 아닌 일반 사용자를 사용하라. 결정했다면 이제 그 사용자로 로그인하여 다음 단계를 진행한다.

2. 컴퓨터에 공개키(public key)와 비밀키(private key)를 만든다. 이게 뭔가? 공개키 암호화 방식을 모른다면 15초간 설명하겠다. 공개키 암호화 방식은 수학적으로 연관된 공개키와 비밀키를 만든다. 그런 다음 공개키는 누구에게라도 줄 수 있지만, 비밀키는 아무에게도 알려주면 안된다. 키들의 수학적 구성상 신기하게도 누구나 공개키를 가지고 내용을 암호화할 수 있지만, 비밀키를 가진 당신만이 암호화한 결과를 해독할 수 있다. 어쨋든 두 키를 만드는 명령은:

ssh-keygen -t rsa

3. 다음과 같이 출력한다:
"Generating public/private rsa key pair"
"Enter file in which to save the key ... "
그냥 enter를 누른다.

4. 그러면 다음과 같이 출력한다:
"Enter passphrase (empty for no passphrase):"
passphrase를 사용하지 않기때문에 enter를 두번 누른다.

5. 그러면 마지막으로:
"Your identification has been saved in ... "
"Your public key has been saved in ... "
방금 만든 공개키 파일명과 위치를 기억하라 (항상 파일명이 .pub로 끝난다).

6. 공개키를 파일을 복사할 모든 원격 리눅스 컴퓨터에 복사한다. scp나 ftp를 사용하여 복사한다. root를 선택했다면 (다시 단계 1의 경고를 주의하라), 키는 /root/.ssh/authorized_keys (철자 조심!)에 있어야 한다. root가 아니고 예를 들어 clyde로 로그인한다면, /home/clyde/.ssh/authorized_keys 에 있어야 한다. authorized_keys 파일이 다른 컴퓨터의 키를 저장하고 있을 수 있기때문에, 파일에 이미 내용이 있다면 (새파일을 덮어쓰지않고) 공개키 파일 내용을 뒤에 추가해야 한다.

이제 끝이다. 별다른 문제가 없다면 파일을 암호없이 원격컴퓨터로 scp할 수 있다. 다시 한번 테스트해보자. 컴퓨터에 있는 'xyz.tgz' 파일을 'bozo'라는 원격컴퓨터의 /tmp 디렉토리로 복사한다

scp xyz.tgz root@bozo:/tmp

와 !!! 암호를 물어보지 않고 복사가 된다!!

일단 암호 하나로 컴퓨터에 로그인하면 모든 원격컴퓨터에 접근할 수 있기때문에 보안에 대해서 주의하라. 그래서 암호를 더 잘 보호해야 한다.

이제 즐길 차례다. 컴퓨터에 있는 'houdini'란 파일을 10개 도시에 흩어져있는 원격컴퓨터의 /tmp 디렉토리로 복사하는 짧은 스크립트를 (5분 안에) 작성해보자. 물론 원격컴퓨터가 100대거나 1000대라도 마찬가지다. 원격컴퓨터들의 이름은: brooklyn, oshkosh, paris, bejing, winslow, rio, gnome, miami, minsk, tokyo. 스크립트는 다음과 같다:

#!/bin/sh
for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo
do
scp houdini root@$CITY:/tmp
echo $CITY " is copied"
done

신기한 마술같다. 스크립트에서 echo 줄은 현재 진행상황을 알려준다.

혹시 쉘스크립트가 생소하다면 좋은 투토리얼이 있다:
http://www.freeos.com/guides/lsst/.

알다시피 scp는 더 강력한 ssh의 일부이다. 위의 6 단계를 마쳤다면 원격컴퓨터에서 명령어를 실행할 수 있다 (물론 암호없이!). 예를 들어, brooklyn 이라는 원격컴퓨터의 시간을 보려면:

ssh brooklyn "date"

이제 두 개념을 합쳐서 진짜로 멋진 스크립트를 만들어보자. 모든 원격 리눅스 컴퓨터를 백업하기란 쉬운 일이 아니다. 아래 스크립트는 각 컴퓨터의 /home 디렉토리를 백업한다. 상용 백업 소프트웨어와 비교하면 기능은 매우 기본적이지만, 가격면에서는 따라올 수 없다. 대부분의 상용 백업 소프트웨어는 백업할 컴퓨터 대수대로 가격을 매긴다. 이런 패키지를 사용한다면 원격컴퓨터 100대에 대한 비용을 지불하는 대신 원격컴퓨터를 한 컴퓨터로 백업하는 스크립트를 사용한라. 그리고 그 컴퓨터에서만 상용 패키지를 사용하면 99대분 가격을 절약할 수 있다 ! 어쨌던 스크립트를 참고하여 자신의 상황에 알맞는 스크립트를 작성할 수 있다. 이 스크립트를 cron 작업에 걸어둔다 (원격컴퓨터에는 필요없다). 주석을 보면 자세한 내용을 알 수 있다:

#!/bin/sh

# 변수는 구별하기위해 대문자로 지었다

# 스크립트를 실행하기 전에 원격컴퓨터마다 '/tmp/backups'라는 디렉토리를
# 만들고, 컴퓨터에는 '/usr/backups'라는 디렉토리를 만들어야 한다

# 컴퓨터에서,
# date 명령어 결과를 보기 좋게 만들어서 "DATE" 변수를 설정한다
#
DATE=$(date +%b%d)

# 'for 반복문'은 세가지 작업을 한다

for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo
do

# 1) 원격컴퓨터의 하드디스크가 꽉차지 않도록 저번에 실행한 스크립트가 만든 tarball을 삭제하고
# 확인을 위해 echo한다
#
ssh -1 $CITY "rm -f /tmp/backups/*.tgz"
echo $CITY " old tarball removed"

# 2) 원격컴퓨터마다 /home 디렉토리를 tarball로 만들어서 /tmp/backups에 저장한다
# tarball 파일명은 구별하기위해 도시명과 시간으로 짓는다
#
ssh $CITY "tar -zcvpf /tmp/backups/$CITY.$DATE.tgz /home/"
echo $CITY " is tarred"

# 3) 원격컴퓨터에 있는 tarball을 /usr/backups 디렉토리로 복사해온다
#
scp root@$CITY:/tmp/backups/$CITY.$DATE.tgz /usr/backups
echo $CITY " is copied"

done

# 나머지 부분은 오류검사용으로 없어도 된다:

# 파일명에 날짜를 포함한 오류파일을 만든다.
# 백업이 안된 컴퓨터가 있다면 이 파일에 기록한다
#
touch /u01/backup/scp_error_$DATE

for CITY in brooklyn oshkosh paris bejing winslow rio gnome miami minsk tokyo

do

# tarball이 복사되었는지 검사한다. 없다면 오류파일에 기록한다
# '||'은 앞에 있는 부분이 참이 아닐때만 뒤에 있는 부분을 실행한다는 뜻이다
#
ls /u01/backup/$CITY.$DATE.tgz || echo " $CITY did not copy" >> scp_error_$DATE

# tarball을 정상적으로 열 수 있는지 검사한다. 문제가 있다면 오류파일에 기록한다.
tar ztvf /u01/backup/$CITY.$DATE.tgz || echo "tarball of $CITY is No Good" >> scp_error_$DATE

done

끝이다. 이 글에서 나는 단지 개념을 설명하려고 예를 들었다. 예제를 "그래로" 사용할 필요가 없다. 배포본에 따라 문법이 다를 수 있지만, 나는 모든 가능성을 다룰 수는 없었다. 예를 들어, Red Hat 6.2 이전 배포본을 사용한다면 문법을 조금 수정해야 한다 (메일을 주면 알려주겠다). 잘 활용하길 바란다.

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:15

rpm 패키지 뽑아내기

블로그 > 패킷 탄 풍경

http://blog.naver.com/jabusunin/20012727371

신의 PC에 현재 설치된 RPM 리스트를 추출하고 이것을 기준으로 rpm 패키지 리스트에서 설치된 패키지 들을 선별해 내는 기능을 가진 스크립트이다.(패키지 버전 무시)

이 스크립트는 sed 와 awk 가 어떻게 사용되는지 보여주기 위한 것이다.

#!/bin/sh
########################################################
clear
echo -en "Make installed rpm list... \n"
rpm -qa > $1

# 시스템에 설치된 패키지 리스트 추출

echo -en "Abstracting Package Names except Version information...\n"
echo -en "SED...\n"
sed 's/-[0-9]/ /' $1 > list.rpm.sed-temp
echo -en "SED... done\n"

# 패키지 리스트에서 버전 정보를 구분하기 위해 공백 생성(단 패키지 이름과 버전은 “-”으로 구분

echo -en "Abstracting Package Names except Version information...\n"
echo -en "SED...\n"
sed 's/-[0-9]/ /' $1 > list.rpm.sed-temp
echo -en "SED... done\n"

# 패키지 리스트에서 패키지 이름만을 추출하여 저장

echo -en "TEMP files delete...\n"
cp list.rpm.awk-temp $1.new
rm -rf list.rpm.sed-temp list.rpm.awk-temp
echo -en "TEMP file delete... done\n"
echo -en "Check this file : $1.new\n"
a=`cat $1.new | wc -l`
echo -en "Total LIST-NUM : $a\n"

# 작업 진행중에 생성된 temp 파일을 삭제하고 추출된 패키지의 개수를 보여준다.

# 아래는 모든 패키지를 모아놓은 디렉토리에서 전 단계에서 추출된 패키지 리스트를 기준으로 패키지를
# 복사해오는 것이다. 각 과정에서 성공인지 실패인지 카운트 하여 결과값을 보여준다.

echo -en "Make dir [pkglist] & copy packagelist...\n"
if [ ! -f pkglist ]; then
mkdir pkglist
fi

# 패키지를 복사해 놓을 디렉토리 생성
b=0
c=0

#패키지 복사 진행 성공과 실패시 카운트

or i in `cat list.rpm.new`
do
cp /경로/RPMS/$i* pkglist/ > /dev/null 2>&1
if [ $? -eq 0 ]; then
b=`expr $b + 1`
echo -en "OK-NUM: $b, COPY : $i\n"
echo "$i" >> OK-LIST
else
c=`expr $c + 1`
echo -en "ERROR-NUM: $c, COPY : $i\n"
echo "$i" >> ERROR-LIST
fi
done
echo -en "...... done\n"
rm -rf list.rpm.new

# 진행 결과 출력

echo -en "Total LIST-NUM:$a, OK-NUM:$b, ERROR-NUM:$c\n"

위 스크립트에서 쓰인 여러 가지 방법들을 응용하면 프로세서의 정보 캐취 라던지, 특정 파일의 검사. 생성, 삭제 등 다양한 스크립트 작성에 도우이 될것이다.

출처 : 리눅스원(주) OS개발팀 (http://www.linuxone.co.kr/bbs/bbsAcademyView.php?id=BBSCAFACATRM&idx=877&perPage=15&pageNum=1&searchOption=&searchText=)

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:14

RPM이란?

블로그 > Micom Study

http://blog.naver.com/salt_mp3/40016208980

리눅스에서 프로그램을 설치하는 방법에는 어떠한 것들이 있을까요?

레드헷에서는 rpm 방식의 설치를 지원하고,
데비안에서는 apt-get 방식을 지원하고,
기타 등등...

리눅스 배포판의 수가 많은 만큼, 프로그램을 설치하는 방식 또한 다양합니다.

이중에서 많은 리눅스 배포판들이 사용하는 패키지 설치 방식은 RPM 방식입니다.

RPM은 Redhat Package Management의 약자로서 레드헷에서 제공하는 패키지 관리툴을 말합니다.

레드헷 리눅스 상에서 다양한 소프트웨어들의 설치, 추가, 삭제 등이 용이하도록 제공되는 툴로서 초기에는 레드헷 계열의 리눅스 배포판에서만 사용되었으나, 그 사용법이 용이하고 편리해서 현재는 대부분의 리눅스 배포판에서 패키지 설치툴로 사용되고 있습니다.

■ RPM 패키지의 구조

[패키지 이름]-[버전]-[릴리이즈 번호].[아키텍쳐].rpm

ex) postgresql-6.3.2-5kr.i386.rpm

지금까지 많은 분들이 리눅스 배포판에서 제공되는 rpm을 가지고,
설치와 제거를 해보셨을 거라 생각됩니다.

오늘 이 강좌를 통해서... 이제는 간단한 패키지들을 직접 만들어서 사용할 수 있는 고급 유저로 거듭나시길 바랍니다. ^^

rpm을 만든다는 것은

① 개발자에 의해 소스RPM(SRPM)으로 1차 만들어진 파일을 받아서 RPM을 추출해 내는 방법

② 원본 소스바이너리 파일을 받아서, 현재의 리눅스 시스템에 맞도록 제작하는 방법

위의 2가지 방법을 말할 수 있습니다.

1번에서의 SRPM은... 개발자가 원본 소스바이너리를 받아서 1차적으로 RPM형식으로 만든 파일을 말하는 것으로, 이것을 이용해 사용자는 쉽고 편리하게 rpm을 만들어서 사용할 수 있습니다.
그리고, 프로그램을 개발하는 개발자 또는 리눅스 프로그램을 수정하여 사용하고자하는 고급유저들에 있어서도 이 소스RPM은 유용하게 사용됩니다.

코어리눅스 2004 Workstation에는 코어리눅스에서 사용되는 프로그램에 대한 SRPM을 CD로 제공하고 있습니다.
4번,5번 CD에 이러한 소스RPM을 제공하고 있으므로,
소스RPM을 필요로 하는 사용자는 유용하게 사용할 수 있습니다.

2번의 방식은 개발자에 의해 SRPM으로 만들어지지 않은 원초적인 소스바이너리를 가지고, RPM을 만드는 방법으로, SRPM에 비해 사용자가 조금더 작업을 해줘야 하는 차이점을 가지고 있습니다.

2번째의 방식을 익히면 1번째의 방식은 자연히 아시게 되리라 생각되어, 아래에는 소스바이너리를 통해 직접 RPM을 제작하는 방법에 대해 설명을 드리겠습니다.

==============================================================================
아래에서 예를 드는, GKrellm이라는 프로그램은, 시스템 정보를 실시간으로 보여주는 모니터링 툴로서, 별다른 의존성 등의 문제없이 쉽게 설치할 수 있는 프로그램으로 교육용으로 적합하다 생각되어 예로 들었습니다.

실제 프로그램 패키징 작업에서는 이외에도 많은 기술 및 방법들이 필요한 관계로, 비교적 간단한 GKrellm을 통해서 설명을 드리겠습니다.
==============================================================================

1. 소스파일 구하기

리눅스배우기에 올려져 있는 GKrellm의 소스파일을 다운로드 합니다.
오픈자료실 GKrellm 받으러 가기

압축을 풀면, gkrellm-2.2.4 라는 디렉토리가 생성됩니다.
# tar xzvf gkrellm-2.2.4.tar.gz

이렇게 다운로드한 소스파일은 컴파일 방식으로 설치를 할 수도 있지만,
여기서는 RPM 제작을 설명해야 하므로, RPM 제작 방식으로 진행하도록 하겠습니다.
※ 소스컴파일 방법은 오픈자료실의 해당 게시물을 참조해 주시기 바랍니다.

2. SPEC 파일 확인하기

보통 리눅스 관련 프로그램을 개발하게 되면, 해당 프로그램을 RPM으로 만들수 있도록 SPEC 파일을 함께 포함하고 있는 경우가 많습니다.
압축을 푼 디렉토리에 가보시면, gkrellm.spec 이라는 파일이 있습니다.
이 파일을 통해서 RPM을 제작할 수 있게 됩니다.

3. 설치를 위한 파일 복사

위의 gkrellm.spec 파일을 아래의 경로에 복사합니다.
# cp gkrellm.spec /usr/src/Kore/SPECS/

다운받은 원본 파일을 아래의 경로에 복사합니다.
# cp gkrellm-2.2.4.tar.gz /usr/src/Kore/SOURCES/

RPM을 제작하기 위해서는 제작 내용을 기술하고 있는 SPEC 파일을 /usr/src/Kore/SPECS/ 디렉토리에 넣어두고, 해당 프로그램의 원본파일을 /usr/src/Kore/SOURCES/ 디렉토리에 넣어두고 작업을 해야 합니다.

4. SPEC 파일의 내용 확인 및 수정

방금 복사한 gkrellm.spec을 열어서 내용을 확인하고 수정이 필요한 부분이 있으면 적절히 수정합니다.

패키징을 해본 결과, 소스파일의 경로가 적절치 않아 패키징이 진행되지 않으므로, 아래 문자을 찾아서 다음과 같이 수정해 줍니다.

Source: http://web.wt.net/~billw/gkrellm/%{name}-%{version}.tar.bz2

(수정)

Source: %{name}-%{version}.tar.gz

※ 이외에는.... 크게 수정하지 않아도 코어리눅스에서 잘 동작하는 환경이므로, 내용만 한번 둘러보시면 되겠습니다.

5. RPM 패키징 시작

드뎌 기다리고 기다리던 패키징 시간입니다.
아래와 같이 입력하고 패키징을 시작해 봅니다.

# rpmbuild -ba -v gkrellm.spec

이상한 문자들이 주루룩~~ 나오면서 리눅스가 혼자서 뭔가를 만들어 냅니다.
정상적으로 종료가 되면, /usr/src/Kore/RPMS/i386/ 디렉토리에 RPM 파일이 만들어 집니다.

# cd /usr/src/Kore/RPMS/i386/
# ls
gkrellm-2.2.4-1.i386.rpm

6. RPM 파일 설치

이제 패키징이 끝났습니다.
위 파일을 가지고, rpm 설치를 진행하면 됩니다.

# rpm -Uvh gkrellm-2.2.4-1.i386.rpm

7. 실행

이제 실행을 해볼까요. ^^

# gkrellm &

화면 귀퉁이에 시스템 모니터링 프로그램이 실행된 것이 보일 겁니다.

이상과 같은 방식으로 다른 패키지들도 RPM으로 만들 수 있습니다.
간단한 프로그램들로부터 시작해서, 하나하나 만들어 보는 기쁨을 느껴 보시기 바랍니다.

출처 : 코어리눅스

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:13

How to 'chroot' an Apache tree with Linux and Solaris

블로그 > wooya510님의 블로그

http://blog.naver.com/wooya510/60005129890

Detailed Steps

Prepare a Chroot-ed File System

Set up the tree anywhere (preferably another disk or a non-system partition to discourage others from making hard links to files outside your web tree), but use a symlink (eg /www) to reference it.
ROOT# mkdir /export/misc/www
ROOT# ln -s /export/misc/www /www
Create the basic directories; bin will be a link to usr/bin
!! NOTE the lack of leading slashes in this example, except where I copy files from the regular file system. Do NOT mix up your chroot-ed tree with your real '/'!
You have been warned!
I have indicated the chroot-ed files in magenta
ROOT# cd /www
ROOT# mkdir -p usr/bin usr/lib lib etc tmp dev webhome
ROOT# ln -s usr/bin bin
/tmp is given special perms.
ROOT# chmod 777 tmp
ROOT# chmod +t tmp
Make the special device /dev/null
ROOT# mknod -m 666 dev/null c 1 3
Set up the timezone info for YOUR timezone (this example uses MET):
ROOT# mkdir -p usr/share/zoneinfo
ROOT# cp -pi /usr/share/zoneinfo/MET usr/share/zoneinfo/
ROOT# cd etc
ROOT# ln -s ../usr/share/zoneinfo/MET localtime
ROOT# cd ..
You will find that perl and/or mod_perl will complain about the lack of locale settings. To fix this install your locale files in the chroot-ed tree:
ROOT# set |grep LANG LANG=en_US
ROOT# mkdir /www/usr/share/locale
ROOT# cp -a /usr/share/locale/en_US /www/usr/share/locale/
Now copy in the shared libraries that provide a very basic chroot-ed file system
ROOT# cp -pi /lib/libtermcap.so.2 /lib/ld-linux.so.2 /lib/libc.so.6 lib/

Test your tree ('cat' will be needed by 'apachectl' later, but is not strictly necessary):
ROOT# cp -pi /bin/ls /bin/sh /bin/cat bin/
ROOT# chroot /www /bin/ls -l /

lrwxrwxrwx   1 0        0               7 Jan 29 09:24 bin -> usr/bindrwxr-xr-x   2 0        0            1024 Jan 29 09:28 devdrwxr-xr-x   2 0        0            3072 Jan 29 13:17 etcdrwxr-xr-x   2 0        0            1024 Jan 29 13:12 libdrwxrwxrwt   2 0        0            1024 Jan 29 09:23 tmpdrwxr-xr-x   5 0        0            1024 Jan 29 09:23 usrdrwxr-xr-x   2 0        0            1024 Jan 29 10:41 webhome

You can remove 'ls'; it was only used for testing:
ROOT# rm bin/ls

Prepare a User and the Naming Service

Here we create the user whom apache will run as, and the necessary naming services for this configuration.

Create a new user that doesn't exist on the system, and give the user a unique name (eg: www) and user id (eg:888). Note that it isn't actually necessary for the user:group to exist in the real authentication (/etc/passwd /etc/group) files. It's up to you..
ROOT# cd /www
ROOT# touch etc/passwd etc/group etc/shadow
ROOT# chmod 400 etc/shadow
Edit these three files. For the sake of this example I am just echoing the data into the files:
ROOT# echo 'www:x:888:888:Web Account:/webhome:/usr/bin/False' > etc/passwd
ROOT# echo 'www:x:888:' > etc/group
ROOT# echo 'www:*:10882:-1:99999:-1:-1:-1:134537804' > etc/shadow
I have given this user no login, and no shell. Just to be complete, compile a 'no-go' shell called False:
ROOT# echo 'int main(int argc, char *argv[]) { return(1); }' > /tmp/False.c
ROOT# cc -o /www/usr/bin/False /tmp/False.c
While we are at it, lets mark the binaries as execute-only:
ROOT# chmod 111 usr/bin/*
Some naming services will be required. With glibc and the Name Service Switch libraries the necessary libraries are not immediately obvious. See 'man nsswitch' for details.
I chose to rely on files and DNS, even though I also run NIS on my home machines.
Note: The libresolv library will be needed as well (This will become evident when PHP is installed).
ROOT# cp -pi /lib/libnss_files.so.2 lib/
ROOT# cp -pi /lib/libnss_dns.so.2 lib/
We will need 3 files to complete the configuration for Naming Service. The contents of these files will depend on your IP and DNS setup. Here we assume that the web server is named ns.mynet.home with IP address 192.168.196.2 (it is actually also my naming server):
# ---- Contents of    etc/nsswitch.conf ----#
passwd: files shadow: files group: files hosts: files dns
# ---- Contents of    etc/resolv.conf ----#
domain mynet.home ## use the IP address of your naming server ## if bind is not installed on your web server #nameserver 192.168.196.xxx ## use this if your web server is a (caching) name server nameserver 127.0.0.1
# ---- Contents of    etc/hosts ----#
127.0.0.1 localhost loopback 192.168.196.2 ns.mynet.home ns www

Compile and Install Apache

Make the top-level directory for the apache install (in this example: /apache); and create a symlink to it in the real tree:
ROOT# mkdir /www/apache
ROOT# ln -s /www/apache /apache
I normally compile and install as an ordinary user (in this example: softs), rather than as 'root'. Note, however, that the installation of apache should be done as root. (See the 'security tips' in the online apache documentation)
In this case I compile sources in /usr/local/src/chr, which is owned by softs:softs
$ cd /usr/local/src/chr
$ tar zxf /path/to/apache_1.3.12.tar.gz
$ cd apache_1.3.12

Edit config.layout so that it includes a special layout called chroot

#   chroot layout.<Layout chroot>   prefix:        /apache   exec_prefix:   $prefix   bindir:        $exec_prefix/bin   sbindir:       $exec_prefix/bin   libexecdir:    $exec_prefix/libexec   mandir:        $prefix/man   sysconfdir:    $prefix/conf   datadir:       $prefix   iconsdir:      $datadir/icons   htdocsdir:     $datadir/htdocs   cgidir:        $datadir/cgi-bin   includedir:    $prefix/include   localstatedir: $prefix/var   runtimedir:    $localstatedir/logs   logfiledir:    $localstatedir/logs   proxycachedir: $localstatedir/proxy</Layout>

Now configure and make:
- non-DSO:
  $ ./configure --with-layout=chroot \ --enable-module=most --enable-module=so
  By enabling the module 'so' you have the possibility of extending your Apache installation later via 3rd-party modules through the DSO+APXS mechanism.
- DSO:
  $ ./configure --with-layout=chroot \ --enable-module=most --enable-shared=max
$ make
ROOT# make install ## I am root!
Copy the other shared libraries that will be needed by Apache as configured in this example. NOTE that other configurations may require other libraries (use ldd to find out).
ROOT# cd /www
ROOT# cp -pi /lib/libm.so.6 /lib/libcrypt.so.1 /lib/libdb.so.3 lib/
ROOT# cp -pi /lib/libdl.so.2 lib/
Do a quick test to see that it worked. The main fields to edit in the configuration file /www//apache/conf/httpd.conf for a quick test are:
User www
Group www
ServerName yourserver.yourdomain.here
Port 8088 ## pick your favourite test port
Here are sample configuration files:
non-DSO: httpd.conf (colorized) httpd.conf (plain text)
DSO: httpd.conf (colorized) httpd.conf (plain text)
Start the daemon (you need to be root):
ROOT# chroot /www /apache/bin/apachectl start
Test the URL:
$ lynx -dump http://yourserver/
Test the URL if on another port, eg: 8088:
$ lynx -dump http://yourserver:8088/
Here is a small perl script that removes most of the comments from the generated config files, for those who want to simplify the file.
This would be a good time to give ownership of the htdocs tree to the web tree 'owner':
ROOT# chown -R 888:888 /www/apache/htdocs

Compile and Install MySQL

MySQL is not installed in the chroot-ed tree; indeed, it should probably be installed on another system. But on my home system it is installed on the same server as apache.

This example includes creating the user and the place where the database will reside, and the creation of the initial database.

Create the user who will own the mysql database -- for example, 777:777 in /home/mysql:
ROOT# groupadd -g 777 mysqldba
ROOT# useradd -c "mysql DBA" -d /home/mysql -u 777 -g 777 -m -n mysql
unpack the source and give ownership of the mysql source tree to the mysql user:
ROOT# mkdir /usr/local/mysql
ROOT# chown mysql:mysqldba /usr/local/mysql
ROOT# cd /usr/local/src
ROOT# tar zxf /path/to/mysql-3.22.27.tar.gz
ROOT# chown -R mysql:mysqldba /usr/local/src/mysql-3.22.27
Now as the mysql user, make a directory for the database, and compile and install mysql:
$ mkdir ~/db ## where the DB will reside
$ cd /usr/local/src/mysql-3.22.27
$ ./configure --localstatedir=/home/mysql/db --prefix=/usr/local/mysql
$ make
$ make install
Create the *MySQL* grant tables (necessary only if you haven't installed *MySQL* before):
$ ./scripts/mysql_install_db
Install and modify the database startup script, changing the database owner from root to 'mysql':
ROOT# cd /usr/local/src/mysql-3.22.27/
ROOT# cp support-files/mysql.server /etc/rc.d/init.d/
ROOT# chmod 755 /etc/rc.d/init.d/mysql.server
ROOT# [ edit /etc/rc.d/init.d/mysql.server: ]
```
mysql_daemon_user=mysql ## so we can run mysqld as this user.
```
ROOT# chkconfig --add mysql.server ## permanently add server to rc scripts
It may be necessary to refresh the shared library cache after installing mysql:
ROOT# /sbin/ldconfig -nv /usr/local/lib
Edit the PATH variable for the mysql owner, and set up the 'root' password for the database (read the documentation!) (and you will probably want to delete the test database and associated entries):
$ [ Edit shell login script .bash_profile: ]
```
     PATH=$PATH:$HOME/bin:/usr/local/mysql/bin
```
$ . ~/.bash_profile ## source it!
$ mysqladmin -u root password '2mUch!data' ## pick your own password!

Compile and Install PHP

Stop the apache daemon, if it is running:
ROOT# chroot /www /apache/bin/apachectl stop
You must first compile PHP, then for non-DSO installs only you must recompile Apache. (You will need to do this each time you upgrade either software package for non-DSO installs.)
$ cd /usr/local/src/chr ## I am NOT root!
$ tar zxf /path/to/php-4.02.tar.gz
$ cd php-4.02
- non-DSO:
  $ ./configure --with-mysql=/usr/local/mysql \ --with-apache=../apache_1.3.12 --enable-track-vars \ --with-config-file-path=/apache/conf --sharedstatedir=/tmp
- DSO:
  $ ./configure --with-mysql=/usr/local/mysql \ --with-apxs=/apache/bin/apxs --enable-track-vars \ --with-config-file-path=/apache/conf --sharedstatedir=/tmp
- DSO:
  (or add CFLAGS switch when mod_ssl was also configured as a DSO module)
  $ CFLAGS=-DEAPI ./configure --with-mysql=/usr/local/mysql \ --with-apxs=/apache/bin/apxs --enable-track-vars \ --with-config-file-path=/apache/conf --sharedstatedir=/tmp
$ make
- non-DSO:
  $ make install
- DSO:
  ROOT# make install
  (You will need to be root for the DSO 'make install' of PHP, since the module goes directly into the module tree: /apache/libexec/ and additionally the apache configuration file is altered.)
Now for the non-DSO installation only, recompile Apache, activating the PHP module:
$ cd ../apache_1.3.12/
$ ./configure --with-layout=chroot \ --enable-module=most --enable-module=so \ --activate-module=src/modules/php4/libphp4.a
$ make
ROOT# make install ## I am root!
More shared libraries (for PHP) are needed in the chrooted tree; check with 'ldd':
- For non-DSO: ldd /apache/bin/httpd
- For DSO: ldd /apache/apache/libexec/libphp4.so
A little for-loop can be used to copy the needed files from /lib and from /usr/lib:
ROOT# cd /www
ROOT# for i in libresolv.so.2 libnsl.so.1 libpam.so.0 ; do > cp -pi /lib/$i /www/lib/ ; done
ROOT# for i in libgd.so.1 libgdbm.so.2 libz.so.1; do > cp -pi /usr/lib/$i /www/usr/lib/ ; done
If you will be needing mysql, you must install that library as well from the place it was compiled into:
ROOT# cp -pi /usr/local/mysql/lib/mysql/libmysqlclient.so.6 /www/usr/lib/
You must edit httpd.conf so that it recognizes .php files, if you have not already done so:
ROOT# cd /apache/conf
ROOT# [ edit /apache/conf/httpd.conf ]
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps
Restart the daemon:
ROOT# chroot /www /apache/bin/apachectl start
For non-DSO installs you can check for compiled-in PHP:
ROOT# chroot /www /apache/bin/httpd -l | grep php
mod_php4.c
Here is a 'hello world' script to test PHP. It should be installed as 'hello.php' (save as type 'text' from netscape), with a copy or a symlink as 'hello.phps' for source-code viewing if you wish. Do not leave it lying around for the public after you have finished testing!

Compile and Install Perl

You can get away with simply copying /usr/lib/perl5 into /www/usr/lib/ ; and copying /usr/bin/perl5.00503 (assuming Red Hat 6.0) into /www/usr/bin/. You would need to check for, and install any missing shared libraries. You should also make a hard link from usr/bin/perl5.00503 to usr/bin/perl in /www as well.

The easy way:

ROOT# cp -a /usr/lib/perl5 /www/usr/lib/perl
ROOT# cp -p /usr/bin/perl5.00503 /www/usr/bin/
ROOT# cd /www/usr/bin
ROOT# ln perl5.00503 perl

Nonetheless (the slightly less easy way :o), I show how to compile and install perl. If you are going to install mod_perl then you really must compile perl here:

Make the nessary links to install into the chroot-ed tree. This example uses /usr/Local inside the tree. The choice of /usr/Local is deliberate -- do not confuse it with /usr/local.
Ever fearful :-O, I installed as 'softs':
ROOT# mkdir /www/usr/Local
ROOT# ln -s /www/usr/Local /usr/Local
ROOT# chown softs:softs /www/usr/Local
Get the source RPM from the redhat sources:
ROOT# rpm -i /path/to/perl-5.00503-2.src.rpm
As the owner (softs) of the source tree, unpack perl.
$ cd /usr/local/src/chr
$ tar zxf /usr/src/redhat/SOURCES/perl5.005_03.tar.gz
Red Hat supplies some patches in the SRPM. You can apply these patches for this distribution as well. This exemple illustrates patching perl from a Red Hat 6.0 distribution.
$ cp /usr/src/redhat/SOURCES/perl*.patch .
$ cd perl5.005_03
$ patch -p1 <../perl5-installman.patch
$ patch -p1 <../perl5.005_02-buildsys.patch
$ patch -p1 <../perl5.005_03-db1.patch
You need to run Configure, accepting most of the defaults from the script. You will also probably want to specify 'none' for the man pages. A few of the defaults to change in my example are listed below:
$ ./Configure
- architecture name? i386-linux
- Installation prefix to use? /usr/Local
- Directories to use for library searches? /lib /usr/lib /usr/Local/lib
- install perl as /usr/bin/perl? n
Compile and install it.
$ make
$ make test
$ make install
Create symlink to perl in the usr/bin tree. If you are not installing mod_perl (see ahead), then you could change ownership of the perl tree to root (but not necessary as long as the permissions on the perl tree are read-only for the web-tree owner: uid '888' in this example):
ROOT# cd /www/usr/bin
ROOT# ln -s ../Local/bin/perl perl

Check the shared libraries and install any missing libraries (depends on your configuration options). No extra libraries are needed in this example:
ROOT# ldd /www/usr/bin/perl

  libnsl.so.1 => /lib/libnsl.so.1 (0x4001b000)  libdl.so.2 => /lib/libdl.so.2 (0x40031000)  libm.so.6 => /lib/libm.so.6 (0x40035000)  libc.so.6 => /lib/libc.so.6 (0x40052000)  libcrypt.so.1 => /lib/libcrypt.so.1 (0x40147000)  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Test your installation:
ROOT# chroot /www /usr/bin/perl -v
```
This is perl, version 5.005_03 built for i386-linux...
```
Set up the example perl cgi bin script installed with the apache server:
ROOT# cd /www/apache/cgi-bin
ROOT# chmod ugo+x *
Start your apache server, and test the example perl cgi bin script installed with the server:
ROOT# chroot /www /apache/bin/apachectl start
$ lynx -dump http://yourserver/cgi-bin/printenv
While you are at it, check test-cgi for shell CGI access as well:
$ lynx -dump http://yourserver/cgi-bin/test-cgi
Finally, REMOVE the execute bit from the example cgi-scripts, or remove them entirely. Don't let the general public have access to these scripts:
ROOT# chmod ugo-x /www/apache/cgi-bin/*

Compile and Install mod_perl

This process assumes that your chroot-ed perl tree is owned by your source-code owner. It this is not the case then change ownership:
ROOT# chown -R softs:softs /www/usr/Local
Extract the source code for mod_perl:
$ cd /usr/local/src/chr
$ tar zxf /path/to/mod_perl-1.24.tar.gz
$ cd mod_perl-1.24
IMPORTANT: Put /usr/Local/bin first in the path before starting configuration. This helps to avoid problems with the configuration finding /usr/bin/perl or /usr/local/bin/perl first in your environment:
$ which perl /usr/bin/perl
$ export PATH=/usr/Local/bin:$PATH ## assuming a bourne shell
$ which perl /usr/Local/bin/perl
Now configure mod_perl; configure the Perl-side of mod_perl, and prepare the mod_perl subdirectory inside apache:
- non-DSO:
  $ perl Makefile.PL APACHE_SRC=../apache_1.3.12/src \ DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1
- DSO:
  $ perl Makefile.PL USE_APXS=/apache/bin/apxs \ EVERYTHING=1
- DSO:
  ( or add the CFLAGS switch when mod_ssl was also configured as a DSO module [and respect any message about apache include files being in unusal places!] )
  $ CFLAGS=-DEAPI perl Makefile.PL USE_APXS=/apache/bin/apxs \ EVERYTHING=1
Now make and install mod_perl into the chroot-ed tree:
$ pwd /usr/local/src/chr/mod_perl-1.24
$ make
- non-DSO:
  $ make install
- DSO:
  ROOT# make install
  (You will need to be root for the DSO 'make install' of mod_perl, since the module goes directly into the module tree: /apache/libexec/ and additionally the apache configuration file is altered.)
For the non-DSO installs only you must recompile apache and reinstall it:
$ cd /usr/local/src/chr/apache_1.3.12/
$ ./configure --with-layout=chroot \ --enable-module=most --enable-module=so \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a
$ make
Stop apache if it was previously running, and install it:
ROOT# chroot /www /apache/bin/apachectl stop
ROOT# make install ## I am root!
For non-DSO installs you can check for compiled-in PHP and mod_perl:
ROOT# chroot /www /apache/bin/httpd -l | grep -E '(php|perl)' mod_php4.c mod_perl.c
Test your mod_perl setup with the Hello.pm. perl module written by Doug MacEachern. You need to install it, edit httpd.conf and restart apache:
$ cp -i Hello.pm \ /www/usr/Local/lib/perl5/site_perl/5.005/i386-linux/Apache/

Insert the mod_perl configuration necessary for Hello.pm into httpd.conf -- example:
```
<Location /hello>  SetHandler perl-script   PerlHandler Apache::Hello</Location> ### Section 3: Virtual Hosts
```
ROOT# chroot /www /apache/bin/apachectl restart
$ lynx -dump http://yourserver:yourPort/hello
```
   Hello, I see you see me with Lynx/2.8.3dev.18 libwww-FM/2.14.
```
If you are finished testing then comment out this entry in httpd.conf. Don't leave unnecessary functionality enabled in your apache configuration.
NOTE: If you need to install other perl modules, you must put /usr/Local/bin first in your path before running perl Makefile.PL:
$ export PATH=/usr/Local/bin:$PATH ## assuming a bourne shell

Compile and Install mod_ssl

I hope you have read the additional notes section if you are planning a DSO install of mod_ssl.

You must compile both openSSL and mod_ssl. I have also elected to compile rsaref version 2.0. You should read the documentation for mod_ssl in the source code table to understand the issues and the options for mod_ssl.

Note that openssl and rsaref provide the include files, libraries and tools to allow you to compile mod_ssl and generate keys, and therefore they are not part of, nor installed into, the chroot-ed tree.

Extract the source code for mod_ssl, openssl and rsaref20:
$ cd /usr/local/src/chr
$ tar zxf /path/to/mod_ssl-2.6.6-1.3.12.tar.gz
$ tar zxf /path/to/openssl-0.9.5a.tar.gz
$ mkdir rsaref-2.0
$ cd rsaref-2.0
$ tar Zxf /path/to/rsaref20.1996.tar.Z
Configure and build the RSA Reference library. Note that on 64-bit architectures you MUST read the documentation in the INSTALL file in the mod_ssl package about portability problems/solutions with rsaref.
$ cd /usr/local/src/chr/rsaref-2.0
$ cp -rpi install/unix local
$ cd local
$ make
$ mv rsaref.a librsaref.a
Configure and build the OpenSSL library.
$ cd /usr/local/src/chr/openssl-0.9.5a
$ ./config -L/usr/local/src/chr/rsaref-2.0/local -fPIC
$ make
$ make test # inspect output for anomolies
You may want to install the package. Of course, it is not installed in the chroot-ed tree. Here I assume that softs:softs owns the /usr/local/ tree, because the default install prefix for openssl is /usr/local/ssl. However, it is not necessary to install this package; you can operate out of the src tree for building mod_ssl (but do NOT run make clean!)
$ make install
Configure mod_ssl:
$ cd /usr/local/src/chr/mod_ssl-2.6.6-1.3.12
$ ./configure --with-apache=../apache_1.3.12
Go into the apache tree to complete the build. Run configure and then make:
$ cd /usr/local/src/chr/apache_1.3.12
- non-DSO:
  $ SSL_BASE=../openssl-0.9.5a RSA_BASE=../rsaref-2.0/local \ ./configure --prefix=/apache --with-layout=chroot \ --enable-module=most --enable-module=so --enable-module=ssl \ --disable-rule=SSL_COMPAT --enable-rule=SSL_SDBM \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a
- DSO:
  $ cd src/modules
  $ make clean ## seems to be necessary if you previously compiled in the apache tree
  $ cd ../../
  $ SSL_BASE=../openssl-0.9.5a RSA_BASE=../rsaref-2.0/local \ ./configure --prefix=/apache --with-layout=chroot \ --enable-module=most --enable-shared=max --enable-shared=ssl \ --disable-rule=SSL_COMPAT --enable-rule=SSL_SDBM
$ make
Install apache again. Stop apache if it was previously running, and then install it:
ROOT# chroot /www /apache/bin/apachectl stop
ROOT# make install ## I am root!
For non-DSO installs you can check for the compiled-in modules:
ROOT# chroot /www /apache/bin/httpd -l | grep -E '(php|perl|ssl)' mod_ssl.c mod_php4.c mod_perl.c
Create the random devices in the chroot-ed tree:
ROOT# cd /www/dev
ROOT# mknod random c 1 8
ROOT# mknod urandom c 1 9
Merge the default configuration file into your current httpd.conf file. I test on a different port from the standard port 80 because I usually already have a web server running on port 80. But for the secure port (port 443) I have no web server running, so I use it immediately.

For the default configuration file the main fields to change for this example follow (and here is an example httpd.conf file):
- User www
- Group www
- ServerName yourserver.yourdomain.here
- Port 8088 ## pick a test port
- Listen 8088 ## in 'IfDefine SSL' section
- Listen 443 ## this is the standard secure port!
- <VirtualHost _default_:443>
- AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps
- # your Hello.pm script for mod_perl testing:
  <Location /hello> SetHandler perl-script PerlHandler Apache::Hello </Location>
- SSLCertificateFile /apache/conf/server.crt
- SSLCertificateKeyFile /apache/conf/server.key
  # in this example I generate the key and crt files into /apache/conf
If you do not already have a server key and certificate then create them. In this example I assume that openssl is in your path because you have installed it. If not, then you should add it to your path (according to this example it is in /usr/local/src/chr/openssl-0.9.5a/apps).

Note also that I am certifying my own key. Presumably you will get a Certifying Authority to sign your key if you are doing any serious work with your web tree (eg: commericial work):
- ROOT# cd /www/apache/conf
- # set up a path of random files:
  ROOT# randfiles='/var/log/messages:/proc/net/unix:/proc/stat:/proc/ksyms'
- # generate the server key
  ROOT# openssl genrsa -rand $randfiles -out server.key 1024
- # generate the signing request (don't add a password when certifying it yourself).
  Note that it is important that the Common Name match your fully-qualified web server name!
  ROOT# openssl req -new -nodes -out request.pem -key server.key
- # sign your own key (validity for one year in this example):
  ROOT# openssl x509 -in request.pem -out server.crt -req \ -signkey server.key -days 365
- Protect your key and certificate:
  ROOT# chmod 400 server.*
- Delete the request file:
  ROOT# rm request.pem
- Optionally encrypt your key (you will have to provide the password each time your start apache, but you may have a very good reason for doing this!):
  ROOT# mv server.key server.key.unencrypted
  ROOT# openssl rsa -des3 -in server.key.unencrypted -out server.key
  ROOT# chmod 000 server.key.unencrypted ## better yet delete it!
- Oops, you changed your mind. You decide to remove the encryption password from your key:
  ROOT# openssl rsa -in server.key -out server.key.un
  ROOT# mv server.key.un server.key
  ROOT# chmod 400 server.key
Start apache first without ssl to make sure it still works:
ROOT# chroot /www /apache/bin/apachectl start
$ lynx -dump http://yourserver:8088/
Re-start apache with ssl and test it with netscape (note that the URL is specified as https):
ROOT# chroot /www /apache/bin/apachectl stop
ROOT# chroot /www /apache/bin/apachectl startssl
$ netscape https://yourserver/
At this point you probably want to edit your web server configuration and set the server on the standard ports 80 and 443 if your test configuration did not use these ports.

Some Security Considerations

See the 'security tips' in the online apache documentation for some help in this area. One extra precaution to take is to change the permissions on the httpd scripts and binaries:
ROOT# chmod ugo-rw /www/apache/bin/*

Escaping Your Chroot-ed Environment

You should be very careful when you set about deliberately escaping from your chroot-ed environment -- you need to assess the risks and benefits. In the UNIX world there is always more than one way to accomplish a task, and you should think about other ways of solving your problem.

Never the less, I provide an example C-utility that implements a customised remote-shell command to email a file generated by forms output to someone. It might be invoked via a cgi-bin script, or via PHP. Example:
```
      <?php      ...      /** construct the file name as $f  **/      $cmd = "/bin/mail \"-s Some-subject-line -t webmaster@localhost -f $f\"";      $op = exec( $cmd, $arr, $retval );      ...      ?>   
```
The file is called wwwmail.c and it is linked here.

Almost anything can be done this way if you code-up your own small utility. I have written a similar utility to exec sqlplus macros for example. But these sorts of utilities are risky, and need to be carefully evaluated.

For this particular problem (emailing forms-output to someone) you might be better off putting files to be mailed in a directory and having a cron job pass through every few minutes and process them...

Cleanup, etc. After Installation

Remove temporary links needed for installation of apache and perl ( remember to put them back if you need to rebuild or upgrade any package ):
ROOT# rm /apache /usr/Local
Automate the startup of Apache by installing a startup script called httpd in /etc/rc.d/init.d/ Here are two examples:
Standard appache on port 80
Apache on ports 80 and 443 (startssl)

Then run chkconfig on it to set the runlevel symbolic links (and verify it with '--list'):
ROOT# chkconfig --add httpd
ROOT# chkconfig --list httpd

httpd       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Automate log file trimming. On a Red Hat system you can specify which log files and which parameters to use in /etc/logrotate.conf. Here is an example file

New: Harvesting files based on RPMs

I haven't had time to totally document this, but you can use the RPM contents from RPMs and create a chroot-ed web tree without compiling the sources. To this end, I have two scripts. I will document this technique more completely later...

Script file based on Red Hat 7.0 that will harvest the RPMs

Script file for creating temporary SSL key and certificate (testing purposes only!!!)

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:11

[Redhat] 호스트명(hostname) 변경하기

### Hostname 변경하기 ###

/etc/HOSTNAME 파일은

부팅 시 /etc/sysconfig/network 파일의 HOSTNAME 부분을 참조하여 저장합니다.

따라서 호스트명을 바꾸고자 할 때에는 /etc/sysconfig/network 파일의 HOSTNAME 부분을 변경한 후, 리부팅을 하거나 네크워크 재시작 명령을 내리면 됩니다.

[root@ ~]# /etc/rc.d/init.d/network restart

[root@ ~]# hostname "hostname" -라우터 호스트네임 변경하는것 같이 해주시면 됩니다

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 14:10

로드밸런싱

블로그 > 인생의 자유는 모두의 권리입니다....

http://blog.naver.com/hdchong/100006713656

로드밸런싱 (load balancing)

만약 www.naver.com으로 접속한다고 치고 네이버에 웹서버가 두대가 있다면

그 서버가 211.218.150.200과 211.218.150.201이라고 치고 각 서버가

L4스위치에 물려있고 사용자는 www.naver.com으로 서비스 요청을 하겠져

처음 사용자가 www.naver.com에 접속을 한다면 211.218.150.200으로 접속이

된다고 칩시다 그러면 그다음 사용자는 211.218.150.201로 접속이 되고요.

이렇게 한쪽으로 치우치지 않게 사용량을 분배하는 것이 서버로드벨런싱입니다.

그리고 한쪽 서버(211.218.150.200)가 죽어버리면 그 서버가 정상동작

을 할때까지 그 포트를 차단시키는 기능도 있읍니다. 이렇게 되면 211.218.150.201

에만 접속이 되고 속도도 처하됩니다. 빨리고쳐야 정상적인 속도를 찾겠져.

만약에 이 기능이 정상적으로 동작을 안하면 어떤 때에는 접속이 되고

어떤 때에는 안돼고 그렇겠져...--; 쓰바 왜 안돼는 거야...TT

그리고 서버는 여러개인데 순차적으로 첫번째 것에만 사용자가 달라붙으면

느려 지겠고요 - 접속 서버가 여러대일 경우 로드밸런싱이 적용 안됀 경우는

서버1-사용자1 서버2-사용자2 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자1 서버2-접속해제 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자1 서버2-사용자5 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-접속해제 서버2-사용자5 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자6 서버2-사용자2 서버3-사용자3 서버4-사용자4 서버5-미접속

이런식으로 서버5부터 다음 서버는 놀겠져...--;

이런 것을 해결하기 위한 기능이져.

이 로드벨런싱은 회선에서도 적용이되져 어느정도 트래픽이 한쪽으로

치우치면 트래픽이 사용량이 적은 쪽으로 데이타를 보내는 기능 등이져....

로드 벨런싱 한마디로 여러 경로를 한쪽으로 치우침없이 균등하게 사용하겠다는 겁니다.

단점이 있다면 하나가 다운되면 트래픽이 한쪽으로 치우쳐서 둘다 퍼지는 경우도 있읍니다.

금강제화 로드밸런싱 구축 사례
NETWORK TIMES 2004년 02월호

지난 1954년부터 ‘최고가 아니면 판매하지 않는다’를 모토로 국내 제화산업을 이끌어온 금강제화

(대표 신용호 www.kumkang.com)는 지난해 늘어나는 내부 트래픽을 제어하기 위해 파이오링크 ‘핑크박스 3000’을 구매했다.

핑크박스가 막 출시된 시점이라 안정성에 대한 검증 등에 대해 의문이 많았지만 최신제품으로 최고의 네트워크를 구축하자는 신념으로 성공적으로 구축, 안전하게 쓰고 있다. 금강제화의 핑크박스 활용

사례를 들여다본다.

지난해 금강제화는 파이어월과 VPN 통합장비를 구입, VPN을 도입하면서 부하분산에 대한 필요성이 두드러졌다. 이에 따라 늘어나는 내부 트래픽 증가를 효율적으로 처리해주기 위해 파이어월과 VPN

통합장비를 추가로 구매할 계획을 세웠다. 또 파이어월/VPN 통합장비 2대 사용으로 이중화 구성을

위한 로드밸런싱 장비가 필요했고 내부 서버 트래픽 부하분산을 위해서 L4 스위치 도입을 고려하게 됐다.

외산장비를 포함한 여러 장비업체들의 제안서를 검토한 결과 금강제화는 신속한 지원과 커스트마이징이 용이한 국산장비를 도입하는 것이 낫겠다는 판단 아래 파이오링크의 L4스위치를 도입하기로 결정했다.

빠른 속도·관리 용이성으로 ‘업무능률 향상’

금강제화가 로드밸런싱을 위해 파이오링크의 L4 스위치 도입을 결정했을 당시는 핑크박스 3000이 출시되기 전이었다. 핑크박스 1508을 도입하기로 결정하고 프로젝트를 진행하던 중 파이오링크에서 핑크박스 3000을 출시했고 금강제화는 내부회의를 거쳐 3000을 도입하기로 변경했다. 물론 이 선택에

대해 반대하는 의견도 만만찮았다.

신규 출시되는 장비에 대한 안정성, 신뢰성 등을 의심, 3000보다 검증된 1508로 가는 게 더 낫지 않겠냐는 의견이 지속적으로 제기됐지만 기왕이면 앞선 성능의 제품으로 더 나은 네트워크를 구성해보자는 전산실의 의견을 수렴하게 됐다.

금강제화 기획조정본부 전산실 김경준 과장은 “1508의 경우 파이어월 로드밸런싱(FLB)과 서버

로드밸런싱(SLB)를 별도로 수행해야했지만 3000은 FLB와 SLB를 한 장비에서 통합 구현할 수 있다”

며 “이런 통합기능으로 인해 5대 이상 구입해야할 L4 스위치 장비를 3대로 줄여 네트워크 구성이

간편해졌다”고 만족해했다.

또 그는 “프로젝트 초기에는 처음 설치해보는 제품이라 여러 가지 문제도 발생했지만 파이오링크에서 최대한 지원해줬고 장기적으로도 최신장비를 구입해야 몇 년동안 업그레이드에 대한 걱정 없이 운영할 수 있을 것 같아 초기의 어려움을 감수했다”고 덧붙였다. 현재 금강제화는 파이어월/VPN용으로

한 대와 파이어월/VPN/SLB용으로 2대, 3세 대의 핑크박스 3000, 그리고 지점망에 핑크박스 1508을 운영하고 있다.

지난해 2월 L4 스위치 장비 도입 계획을 세운 후 자체 개발기간 6~7개월을 거쳐 실제로는 9월부터

설치에 들어갔고 약 한달간의 안정화기간을 거쳐 지난해 10월말부터 본격적으로 가동하고 있는 상태다. 현재까지는 아무런 장애 없이 늘어난 트래픽을 효과적으로 제어하며 만족스럽게 쓰고 있다.

김 과장은 “핑크박스 3000이 내부 트래픽을 각 서버의 상황에 따라, 트래픽의 종류에 따라 로드밸런싱이 가능해 약 50% 이상 속도가 향상됐다”며 “빨라진 속도로 인해 직원들의 만족도도 높아져 업무능률이 향상됐다”고 언급했다.

금강제화 네트워크 구성도

가격대비 우수한 성능·부하부산 ‘탁월’

금강제화에 설치된 다계층 스위치 ‘핑크박스 3000’은 로드밸런싱 기능을 통해 서버, 캐시 서버, 네트워크 보안 장비(파이어월, VPN), IDS 등의 높은 가용성은 물론이고, 원활한 처리 속도를 제공하는 제품이다. 이 제품은 패킷을 고속 처리하고 동시에 100만 개 이상의 세션을 처리할 수 있어 사용자가 많은

대규모 환경에 적합하다.

일반적인 다계층 스위치의 용도가 웹 서버, 캐싱 서버, 파이어월 등 각종 서버의 로드밸런싱, 장애복구 기능을 돕는 데 있는 만큼, 핑크박스 3000도 이런 기능을 기본으로 제공한다. 여러 종류의 로드밸런싱 기능을 동시에 지원할 수 있도록 설계돼 핑크박스 3000 1대로 다양한 로드밸런싱 용도로 사용할 수

있다. 금강제화가 특히 만족하는 부분도 바로 이러한 여러 종류의 로드밸런싱 기능을 동시에 지원할 수 있다는 점이다.

금강제화는 VPN 로드밸런싱, 서버 로드밸런싱, 파이어월 로드밸런싱 등 다양한 로드밸런싱 기능을 한 장비에서 동시에 구현함으로 관리 편이성과 네트워크 구성 용이성 등의 이점을 톡톡히 누리고 있다.

김경준 과장은 “VPN 구축과 함께 문제로 대두된 VPN 트래픽을 효과적으로 처리해줄 방법을 찾고

있었는데 핑크박스의 VPN 로드밸런싱의 경우, 지점 VPN 장비에서 센터 장비로의 접속 뿐 아니라,

센터에서 지점으로의 접속도 허용함으로써 VPN 네트워크를 100% 활용할 수 있는 환경을 제공한다”며 “따라서 이런 다양한 로드밸런싱을 통해 인터넷 서비스의 성능을 극대화하고 트래픽 관리를 고차원적으로 수행할 수 있다”고 언급했다.

또 핑크박스 3000은 중요한 대역폭 관리를 위한 QoS (Quality of Service)기능은 트래픽 유형별

대역폭 보장, 사용자의 우선 순위 설정에 따른 대역폭 제한을 통해 제공한다. IP 어드레스, 포트 번호 수준의 트래픽 구분 외에도 URL, 쿠키, HTTP 헤더 등 7계층 정보에 의한 트래픽 구분을 통해 정교한 대역폭 관리 기능을 제공하는 것도 강점이다. 이런 QoS 기능으로 인해 주요 트래픽과 단순 인터넷

접속 트래픽 등을 분류, 업무에 중요한 트래픽에 우선 순위를 할당할 수 있어 업무효율성도 증가했다.

침입탐지· 바이러스월 등 보안 기능 추가 예정

한편 금강제화는 강남지점에 네트워크 로드밸런싱 장비인 ‘핑크박스 1508’을 설치, 운영중이다. 이 장비는 전용선을 포함한 다수(7회선)의 초고속인터넷 회선을 결합해 하나의 회선처럼 동작하게 함으로써 대용량(최대 100Mbps)의 안정적인 인터넷 접속을 제공해 최고 100Mbps의 대역폭 확보가 적은

비용으로 가능하다. 다중의 회선을 사용하기 때문에 안정성도 매우 뛰어나다.

김 과장은 “지난 1년동안 강남지점에 핑크박스 1508을 설치 후 128Kbps의 전용선과 ADSL 3회선을 동시에 사용하게 될 경우와 E2 1회선을 사용하는 경우를 비교해봤더니 전자의 경우가 속도에서도 월등할 뿐만 아니라 최소 천 만원 이상의 비용절감이 가능한 것으로 나타났다”며 “향후에는 보안 등의 문제로 인해 E1, T3 등으로 회선을 증설, 양재동 본사쪽으로 트래픽을 통합해야겠지만 현재로서는 강남지점의 운영상태가 좋아 강남지점외의 타 지점, 영업소 등을 같은 방법으로 운영할 것으로 고려하고 있다”고 언급했다.

향후 금강제화는 전국 매장 280곳과 계열사 등을 통합하면 약 600노드 이상이 될 것으로 예상, 이를 통합하게 되면 발생할 대량 트래픽에도 로드밸런싱 장비로 적절히 제어할 수 있을 것으로 기대하고 있다. 또 침입탐지, 바이러스월 등 보안장비를 추가로 도입, 안전한 네트워크 구성을 위해 만전을 기할 방침이다.

[생각]===============================================================

저희도 L4장비를 검토중에 있는데..제품에 대한 기술적인 자료등이 오픈이 안되어 비교하기가

수월하지 않더군요..L4장비는 서버,VPN,방화벽등의 장비 사이에 설치하며 트래픽 로드밸런싱

기능으로 장비를 효율적으로 사용하고 장애시에 트래픽을 우회함으로써 장애예방이 주 목적이지요

인터뷰에서는 50% 속도 향상이라고 표현했는데 방화벽 이중화로 인한 향상이며 L4장비는

보조적인 지원이라고 봐야 하겠지요 ^^

대기업에서도 수익율로 네트워크 장비개발에 미온적인데 국내벤쳐에서 개발하여 동남아 시장에

판로개척을 하는것을 보면 흐믓합니다

지난 1954년부터 ‘최고가 아니면 판매하지 않는다’를 모토로 국내 제화산업을 이끌어온 금강제화(대표 신용호 www.kumkang.com)는 지난해 늘어나는 내부 트래픽을 제어하기 위해 파이오링크 ‘핑크박스 3000’을 구매했다.

핑크박스가 막 출시된 시점이라 안정성에 대한 검증 등에 대해 의문이 많았지만 최신제품으로 최고의 네트워크를 구축하자는 신념으로 성공적으로 구축, 안전하게 쓰고 있다. 금강제화의 핑크박스 활용사례를 들여다본다.

지난해 금강제화는 파이어월과 VPN 통합장비를 구입, VPN을 도입하면서 부하분산에 대한 필요성이 두드러졌다. 이에 따라 늘어나는 내부 트래픽 증가를 효율적으로 처리해주기 위해 파이어월과 VPN 통합장비를 추가로 구매할 계획을 세웠다. 또 파이어월/VPN 통합장비 2대 사용으로 이중화 구성을 위한 로드밸런싱 장비가 필요했고 내부 서버 트래픽 부하분산을 위해서 L4 스위치 도입을 고려하게 됐다.

외산장비를 포함한 여러 장비업체들의 제안서를 검토한 결과 금강제화는 신속한 지원과 커스트마이징이 용이한 국산장비를 도입하는 것이 낫겠다는 판단 아래 파이오링크의 L4스위치를 도입하기로 결정했다.

빠른 속도·관리 용이성으로 ‘업무능률 향상’

금강제화가 로드밸런싱을 위해 파이오링크의 L4 스위치 도입을 결정했을 당시는 핑크박스 3000이 출시되기 전이었다. 핑크박스 1508을 도입하기로 결정하고 프로젝트를 진행하던 중 파이오링크에서 핑크박스 3000을 출시했고 금강제화는 내부회의를 거쳐 3000을 도입하기로 변경했다. 물론 이 선택에 대해 반대하는 의견도 만만찮았다.

신규 출시되는 장비에 대한 안정성, 신뢰성 등을 의심, 3000보다 검증된 1508로 가는 게 더 낫지 않겠냐는 의견이 지속적으로 제기됐지만 기왕이면 앞선 성능의 제품으로 더 나은 네트워크를 구성해보자는 전산실의 의견을 수렴하게 됐다.

금강제화 기획조정본부 전산실 김경준 과장은 “1508의 경우 파이어월 로드밸런싱(FLB)과 서버 로드밸런싱(SLB)를 별도로 수행해야했지만 3000은 FLB와 SLB를 한 장비에서 통합 구현할 수 있다”며 “이런 통합기능으로 인해 5대 이상 구입해야할 L4 스위치 장비를 3대로 줄여 네트워크 구성이 간편해졌다”고 만족해했다.

또 그는 “프로젝트 초기에는 처음 설치해보는 제품이라 여러 가지 문제도 발생했지만 파이오링크에서 최대한 지원해줬고 장기적으로도 최신장비를 구입해야 몇 년동안 업그레이드에 대한 걱정 없이 운영할 수 있을 것 같아 초기의 어려움을 감수했다”고 덧붙였다. 현재 금강제화는 파이어월/VPN용으로 한 대와 파이어월/VPN/SLB용으로 2대, 3세 대의 핑크박스 3000, 그리고 지점망에 핑크박스 1508을 운영하고 있다.

지난해 2월 L4 스위치 장비 도입 계획을 세운 후 자체 개발기간 6~7개월을 거쳐 실제로는 9월부터 설치에 들어갔고 약 한달간의 안정화기간을 거쳐 지난해 10월말부터 본격적으로 가동하고 있는 상태다. 현재까지는 아무런 장애 없이 늘어난 트래픽을 효과적으로 제어하며 만족스럽게 쓰고 있다.

김 과장은 “핑크박스 3000이 내부 트래픽을 각 서버의 상황에 따라, 트래픽의 종류에 따라 로드밸런싱이 가능해 약 50% 이상 속도가 향상됐다”며 “빨라진 속도로 인해 직원들의 만족도도 높아져 업무능률이 향상됐다”고 언급했다.

가격대비 우수한 성능·부하부산 ‘탁월’

금강제화에 설치된 다계층 스위치 ‘핑크박스 3000’은 로드밸런싱 기능을 통해 서버, 캐시 서버, 네트워크 보안 장비(파이어월, VPN), IDS 등의 높은 가용성은 물론이고, 원활한 처리 속도를 제공하는 제품이다. 이 제품은 패킷을 고속 처리하고 동시에 100만 개 이상의 세션을 처리할 수 있어 사용자가 많은 대규모 환경에 적합하다.

일반적인 다계층 스위치의 용도가 웹 서버, 캐싱 서버, 파이어월 등 각종 서버의 로드밸런싱, 장애복구 기능을 돕는 데 있는 만큼, 핑크박스 3000도 이런 기능을 기본으로 제공한다. 여러 종류의 로드밸런싱 기능을 동시에 지원할 수 있도록 설계돼 핑크박스 3000 1대로 다양한 로드밸런싱 용도로 사용할 수 있다. 금강제화가 특히 만족하는 부분도 바로 이러한 여러 종류의 로드밸런싱 기능을 동시에 지원할 수 있다는 점이다.

금강제화는 VPN 로드밸런싱, 서버 로드밸런싱, 파이어월 로드밸런싱 등 다양한 로드밸런싱 기능을 한 장비에서 동시에 구현함으로 관리 편이성과 네트워크 구성 용이성 등의 이점을 톡톡히 누리고 있다.

김경준 과장은 “VPN 구축과 함께 문제로 대두된 VPN 트래픽을 효과적으로 처리해줄 방법을 찾고 있었는데 핑크박스의 VPN 로드밸런싱의 경우, 지점 VPN 장비에서 센터 장비로의 접속 뿐 아니라, 센터에서 지점으로의 접속도 허용함으로써 VPN 네트워크를 100% 활용할 수 있는 환경을 제공한다”며 “따라서 이런 다양한 로드밸런싱을 통해 인터넷 서비스의 성능을 극대화하고 트래픽 관리를 고차원적으로 수행할 수 있다”고 언급했다.

또 핑크박스 3000은 중요한 대역폭 관리를 위한 QoS (Quality of Service)기능은 트래픽 유형별 대역폭 보장, 사용자의 우선 순위 설정에 따른 대역폭 제한을 통해 제공한다. IP 어드레스, 포트 번호 수준의 트래픽 구분 외에도 URL, 쿠키, HTTP 헤더 등 7계층 정보에 의한 트래픽 구분을 통해 정교한 대역폭 관리 기능을 제공하는 것도 강점이다. 이런 QoS 기능으로 인해 주요 트래픽과 단순 인터넷 접속 트래픽 등을 분류, 업무에 중요한 트래픽에 우선 순위를 할당할 수 있어 업무효율성도 증가했다.

침입탐지· 바이러스월 등 보안 기능 추가 예정

한편 금강제화는 강남지점에 네트워크 로드밸런싱 장비인 ‘핑크박스 1508’을 설치, 운영중이다. 이 장비는 전용선을 포함한 다수(7회선)의 초고속인터넷 회선을 결합해 하나의 회선처럼 동작하게 함으로써 대용량(최대 100Mbps)의 안정적인 인터넷 접속을 제공해 최고 100Mbps의 대역폭 확보가 적은

비용으로 가능하다. 다중의 회선을 사용하기 때문에 안정성도 매우 뛰어나다.

김 과장은 “지난 1년동안 강남지점에 핑크박스 1508을 설치 후 128Kbps의 전용선과 ADSL 3회선을 동시에 사용하게 될 경우와 E2 1회선을 사용하는 경우를 비교해봤더니 전자의 경우가 속도에서도 월등할 뿐만 아니라 최소 천 만원 이상의 비용절감이 가능한 것으로 나타났다”며 “향후에는 보안 등의 문제로 인해 E1, T3 등으로 회선을 증설, 양재동 본사쪽으로 트래픽을 통합해야겠지만 현재로서는 강남지점의 운영상태가 좋아 강남지점외의 타 지점, 영업소 등을 같은 방법으로 운영할 것으로 고려하고 있다”고 언급했다.

향후 금강제화는 전국 매장 280곳과 계열사 등을 통합하면 약 600노드 이상이 될 것으로 예상, 이를 통합하게 되면 발생할 대량 트래픽에도 로드밸런싱 장비로 적절히 제어할 수 있을 것으로 기대하고 있다. 또 침입탐지, 바이러스월 등 보안장비를 추가로 도입, 안전한 네트워크 구성을 위해 만전을 기할 방침이다.

[미니 인터뷰] 김경준 금강제화 기획조정본부 전산실 과장

통합관리·성능우수·업무 효율성 ‘만족’

■ 핑크박스 3000을 도입한 이유는.

장애 발생 시 빠른 지원을 받으려면 외산보다 국산이 낫고 위치도 가까운 곳에 있는 회사가 좋겠다는 판단 아래 여러 외산벤더의 솔루션을 포함, 다양한 제품들을 검토해본 끝에 파이오링크의 로드밸런싱 장비를 구입하기로 결정했다. 실제로 예전에 통합보안의 중앙관리를 위해 국산 보안제품을 쓰다가 외산으로 바꿨더니 특별한 문제, 우리가 원하는 요구에 대한 세심한 관리가 부족한 것을 경험했다. 따라서 커스터마이징이 손쉽고 원할 때 지원이 가능한 국산장비가 낫다고 판단했고 실제 운영해본 결과 파이오링크의 빠른 지원에 만족한다.

■ 도입한 핑크박스 3000에 만족하는지.

핑크박스 3000을 도입할 당시 초기 출시된 장비라 실제 구축경험, 운영 안정성 등에 대한 검증이 없어 초반에는 좀 애를 먹었다. 물론 현재는 만족스럽게 잘 쓰고 있고 우리는 초기 출시에 따른 위험을 감수하면서 도입을 결정했으니 약간의 어려움도 감수할 수 있었다.

그러나 로드밸런싱을 위해 장비를 신규 도입하려는 회사들은 레퍼런스를 통해 테스트를 끝낸 장비를 도입했으면 한다. 신규장비를 도입한다고 해서 기존 업무에 있어 지장을 줘서는 안된다. 따라서 기존업무의 안정성을 보장할 수 있는 검증된 장비를 도입하는 것이 좋다.

■ 향후 추가도입이나 활용계획은.

현재 구축된 네트워크 상태에 만족하지만 침입탐지, 바이러스월 등을 보강, 해킹이나 바이러스 등에서 네트워크를 안전하게 보호할 계획이다. 또 향후 전국 지점, 계열사 등을 통합, 운영하게 될 경우를 대비해 네트워크 안정성, 대역폭 용량 등을 풍부히 갖춰놓을 방침이다.

금강제화 전산실은 타 회사들에 비해 전산인원이 많은 편이다. 최대 48명까지 전산담당 인원이 있었을 정도인데 이는 자체 개발, 자체 유지보수를 기본으로 하기 때문이다. 또 각 매장마다 설치돼 있는 수 백대의 POS 장비들을 관리하기 위해서는 전산인원이 많이 필요하다. 이번 로드밸런싱 장비 설치에도 도입을 결정한 시점이 2월이었지만 장비의 네트워크 구성, 설치 등 SI적인 작업은 자체적으로 수행했다. 앞으로도 금강제화는 자체 관리, 자체 개발을 기본으로 효율적인 네트워크 구축을 위해 최선을 다할 방침이다.

Windows2000Pro를 사용해서 로드밸런싱게이트웨이를 구성하신다는것이신지(이건 윗분말씀처럼 다른OS와 추가로 더 깔아야합니다.) 아니면 Windows2000들을 로드밸런싱을 하신다는것이신지...

보통 로드밸런싱은 후자쪽을 말하는데
장비로 해결하는경우(L4스위치,SLB장비 같은말)가있고
고전적으로 DNS round robin방식으로 하는방법도 있고..

L4로 하는경우에는 L4가 어떤모드인지...

하여튼 복잡합니다. --;;

관련내용은 궵검색에서 SLB나 L4 switch등을 검색해보시면 많은 솔류션이 나올껍니다.

돈안들이고 하는방법은 DNS round robin이죠. 효율성은 떨어지지만 돈이안드니...

그저 밑에서버가 IP가 111.111.111.1부터 4까지 4대라면

www.aaa.com에 IP를 111.111.111.1부터 4까지 등록을해놓으면

www.aaa.com을 접근할때 차례대로 순번대로 1부터4까지 골고루 나누어서 접속하게 해줍니다.

참고로 지금 nslookup을 해보니

www.naver.com은 IP가 한갠데..이건 L4를 사용해서 할테고...

naver.com은 DNS round robin이네요.
Name: naver.com
Addresses: 211.218.150.81, 211.218.150.82, 211.218.150.93, 211.218.150.96
211.218.150.98, 211.218.150.115, 211.218.150.132, 211.218.150.134, 211.218.150.135
211.218.150.139, 211.218.150.140, 211.218.150.152, 211.218.150.157, 211.218.150.193
211.218.150.53

이럴경우에는 위에꺼중에 아무거나 하나잡아서 쓰게됩니다.(실제로는 위의 IP중 몇개는 역시 L4를 사용하여 또 로드밸런싱을 할 경우도 있죠)

========추가

쪽지로 물어보셨는데...

NIC(LAN카드) 두개를 묶는거는

로드발란싱이라기보다는 그저 Network Bandwidth를 늘리는(100메가 두개면 200M로)쪽이겠지요.

그런건 보통 딜리게이션(맞나-.-ㅋ)이나 Bonding이라고 부릅니다.

윈도에서는 잘 모르겠구요 --;;; (L4등을 사용한다면 그저 L4에 메인IP를 주고 각 NIC에 private address를 부여해서 L4에서 밸런싱을하는방법과 L2스위치(흔히 우리가 아는 스위치허브)에서 기능을 지원하고 서버에서 지원할경우 하는방법도 있는데 그런걸 주로사용합니다.)

제가 MS쪽은 잘 몰라서 --;;;

다른 머신들에서는 보통 그런전용의 NIC이 나옵니다.

예를들어 Sun의 경우에는 Quad Lan Card(qfe)라고해서 100M NIC 4개가 붙은걸 팝니다.(400M bandwidth가 나오겠죠. 뭐 원래 100M가 full 100M가 나오는경우는 없지만요)
그리고 요즘은 기가빗장비들이 많아져서 그냥 기가빗NIC을 사용해버리는 추세입니다.(기가빗하나붙이면 뭐 거의 Bandwidth는 끝나버리니까요. 어짜피 전용선이 못봐쳐주는데요 ^^)

그리고 포트별로 NIC을 다르게한다던지 그런건 L4의 도움으로 보통 구현합니다. 서버단에서의 설정은 귀찮기만하고 뭐 그렇거든요 ^^

로드밸런싱 (리눅스 편)

심마로, 리눅스원(주) 연구원

1. 리눅스 로드 밸런싱

(1) 로드밸런싱이란?

(2) 리눅스 로드 밸런싱의 목적

(3) 리눅스 로드 밸런싱의 구성

2. 리눅스 로드 밸런싱 솔루션

(1) 리눅스 가상 서버 LVS(Linux Virtual Server)

(2) 레드햇의 피라냐(RedHat Piranha)

(3) 기타 상용 솔루션

3. 리눅스 고가용성 솔루션

(1) 리눅스 고가용성 솔루션의 개요

(2) Kimberlite/Convolo Cluster

(3) OPS(Oracle Parallel Server)

4. 프로세스 마이그레이션

(1) 프로세스 마이그레이션 개요

(2) Mosix

(3) Scyld

5. 맺음말

1. 리눅스 로드 밸런싱

(1) 로드밸런싱이란?

로드밸런싱을 간단히 정의하자면, 여러 컴퓨터에 작업을 균등하게 분산시킴으로써 한 대의 컴퓨터를 사용하는 것에 비해 짧은 시간에 사용자가 원하는 작업을 수행하고자 하는 것이다. 수십 대의 컴퓨터를 사용한다고 하더라도 주로 한 대의 컴퓨터에서 작업이 이루어진다면 원하는 성능 향상을 얻을 수 없을 것이기 때문에, 작업을 "균등"하게 분산시키는 것이 중요하다.

로드밸런싱을 위해서 전용 하드웨어를 사용할 수도 있고, 일반적인 컴퓨터와 일반적인 운영체제를 사용할 수도 있으며, 또한 처리 수준 측면에서는 응용 프로그램 레벨과 IP 레벨에서 로드 밸런싱을 처리할 수 있다. 이 글에서는 주로 일반적인 운영체제를 사용하는 경우, 그리고 IP 레벨에서 로드밸런싱을 처리하는 경우를 다룰 것이다.

(2) 리눅스 로드밸런싱의 목적

리눅스 로드밸런싱의 목적은 리눅스 서버를 클러스터로 연결하여 전체적으로 저렴한 가격에 높은 성능을 제공하는 것이다. SMP 시스템이라고 부르는 공유 메모리 방식의 서버 시스템의 경우, CPU 갯수가 2개, 4개, 8개 등으로 증가함에 따라서 가격이 기하급수적으로 증가하기 때문에, 확장성이 좋지 못하다. 따라서 수십 ~ 수백 대의 서버가 요구되는 경우 클러스터 설정을 사용하게 된다. 또한 수십 ~ 수백 대의 서버에서 사용하는 운영체제로서 리눅스를 사용하는 것이 안정적이고 성능이 우수하며, 가격도 저렴하기 때문에 효과적이다. 클러스터 설정을 위해 사용되는 하드웨어는 공간 비용을 절약하기 위해 1.75"(약 4.5cm) 높이의 1U 랙 마운트 케이스를 사용하는 추세이다.

물론, 응용에 따라서는 수십 개의 CPU가 공유 메모리 방식으로 연결된 SMP 시스템을 요구하는 경우도 있다. 예를 들어 Sun사의 Starfire 구조(Sun Enterprise 10000)의 경우 64 CPU까지 지원한다. 하지만 응용 프로그램의 수정을 통해서 로드밸런싱 클러스터에서 실행시키는 것이 가능하다면, SMP 시스템에 비해 높은 가격대 성능비를 얻을 수 있다.

그리고, 서버의 수가 증가함에 따라 에러가 발생할 확률이 증가하므로 이를 해결하기 위해 추가적으로 고가용성(High Availability)을 제공한다. 고가용성은 전체 시스템의 각 부분에서 모두 필요한데, 이에 대해서는 3절에서 설명한다.

(3) 리눅스 로드밸런싱의 구성

이 글에서는 리눅스 로드 밸런싱을 위해 다음과 같은 일반적인 구성을 가정하였다.

<논리적인 구성>

<물리적인 구성>

<전체적인 시스템 구성>

로드밸런서 2대 failover

서버 노드 8대
데이타베이스 서버 노드 두 대
공유 SCSI 외장형 스토리지
100 Mbps 이더넷 스위치 * 2

로드 밸런서 2대는 Active-Passive 설정(두 대의 서버가 동시에 사용자의 요청을 처리하는 것이 아니라, Active 상태인 하나의 서버만 사용자의 요청을 처리하며, Passive 상태인 서버는 Acitve 상태인 서버가 제대로 동작하는지 감시하고 있다가, 오동작을 하는 경우 사용자의 요청을 넘겨 받아 작업을 처리한다)이며, 한 대로 설정하는 경우 발생할 수 있는 로드 밸런서의 에러로 인한 전체 서비스의 중단을 막기 위해 2대로 설정한다. 로드 밸런서를 위한 하드웨어는 CPU 성능이나 메모리 용량이 크게 요구되지 않지만, 하드웨어의 안정성이 중요하다.

서버 노드는 로드 밸런서에서 작업을 분배시켜 준 것을 받아서 실제로 작업을 수행한다. 여기서는 8대의 서버 노드를 가정하였다. 그렇지만, 실제로는 설정에 따라서 수십 ~ 수백 대의 서버 노드를 연결할 수 있다. 1U 랙마운트 케이스에 듀얼 CPU 설정을 많이 사용한다.

데이터베이스 서버 노드 두 대 역시 Active-Passive 설정이며, 이 부분에 대해서는 3절, "리눅스 고가용성 솔루션"에서 자세히 설명한다.

공유 SCSI 외장형 스토리지는 데이터베이스 서버 노드 두 대에 외장 SCSI 케이블로 연결되며, 스토리지 내부는 RAID로 구성되어 서비스의 중단을 방지한다.

100Mbps 이더넷 스위치는 이 시스템의 로드 밸런서 및 서버 노드들 사이의 연결을 위해 사용된다. 앞의 설정에서는 외부 인터넷과 서버의 연결, 서버와 데이터베이스 연결을 위해 별도의 이더넷 스위치를 사용한다고 가정했다. 그러나, 이더넷 스위치의 포트가 넉넉하다면, 로드밸런서와 서버 노드 사이의 연결과, 서버 노드와 데이터베이스 서버 노드 사이의 연결을 모두 하나의 이더넷 스위치로 연결할 수 있다.

이와 같은 시스템 설정에서 오동작으로 인해 전체 시스템의 서비스 중단을 일으킬 수 있는 부분은 개별 서버가 아니라 서버간의 연결을 담당하는 네트워크 스위치이다. 따라서 품질이 우수한 이더넷 스위치를 사용할 필요가 있다.

(로드밸런싱 솔루션 중에서 로드 밸런서 2대에 의한 failover만으로는 로드 밸런서의 에러에 의한 서비스 중단을 방지하기에 불충분하다고 주장하며, 따라서 살아 있는 다른 서버로 로드 밸런서의 이전을 제공하는 솔루션들도 있다. 하지만, 필자의 생각으로는 이와 같은 시스템 설정에서 과부하 상황에서 문제가 발생할 수 있는 부분은 이더넷 스위치를 비롯한 네트워크 인터커넥션 부분이며, 이에 대한 충분한 품질 검사가 필요하다고 생각한다. 또한, 계속되는 과부하 상황에서 로드밸런서가 다른 서버로 이전되기 위한 네트워크 부하의 증가와, 이전 후의 충분하지 못한 서버 용량 때문에 정상적인 서비스 지속은 불가능할 것으로 생각한다)

박스 : <IBM의 올림픽 사이트 관련>

1998년 나가노 동계 올림픽 공식 홈페이지는 당시에 다음과 같은 기록을 세웠다. (기네스북 인증)

* 사상 최고의 가장 인기있는 인터넷 이벤트 - 공식적으로 감사된 수치는 올림픽

게임 16일동안 6억 3천4백만 요청.

* 1분동안 가장 많은 히트를 기록한 인터넷 사이트 - 공식적으로 감사된 수치는 여자

자유종목 피겨스케이팅 경기중의 1분동안 110,414히트를 기록.

이 사이트의 구축을 위해 TCP 수준에서의 라우팅에 기반한 로드 밸런싱 기법을 사용하였다. 클러스터의 한 노드는 TCP 라우터라고 불리는데, 클라이언트의 요구를 라운드 로빈 또는 다른 방법을 사용해서 클러스터 내의 웹 서버 노드로 전송한다. 라우터의 도메인 이름과 IP 주소는 외부에 공개되어 있고, 클러스터의 다른 노드들은 클라이언트에서는 보이지 않는다. (만약 둘 이상의 TCP 라우터 노드가 있는 경우, RR-DNS가 하나의 도메인 이름을 여러 TCP 라우터로 대응시킨다) 클라이언트는 요청을 TCP 라우터 노드로 보내고, 이 TCP 라우터 노드는 특정 TCP 연결에 속한 모든 패킷을 서버 노드들 중의 하나로 보낸다. TCP 라우터는 어느 노드로 라우팅 할 것인지 결정하기 위해 부하(load)에 기반한 다른 알고리즘을 사용할 수도 있고, 부하에 기반한 알고리즘보다 성능이 떨어지는 라운드-로빈 방법을 사용할 수도 있다. 서버 노드는 TCP 라우터를 건너뛰고 클라이언트에 직접 응답한다. 요구 패킷은 응답 패킷에 비하면 작기 때문에, TCP 라우터에는 작은 부하만 걸린다.

TCP 라우터 스킴은 DNS 기반 솔루션보다 좋은 로드 밸런싱을 제공하고, 클라이언트나 네임 서버의 캐싱 문제를 피할 수 있다. 라우터는 개별 서버 노드의 부하를 고려한 더 좋은 로드 밸런싱 알고리즘을 사용할 수도 있다. TCP 라우터는 웹 서버 노드의 고장을 인식하여 사용자의 요청을 사용 가능한 웹 서버 노드로만 전송할 수 있다. 시스템 관리자는 TCP 라우터의 설정을 변경하여 웹 서버 노드를 추가, 삭제할 수 있고, 이를 통해 웹 서버 클러스터를 관리할 수 있다. 백업 TCP 라우터를 설정하여, TCP 라우터 노드의 고장을 처리할 수 있고, 백업 라우터는 정상 동작시에는 웹 서버로 동작할 수 있다. 1차 TCP 라우터의 고장을 인식하면, 백업 라우터는 클라이언트의 요청을 자신을 제외한 남아있는 웹 서버 노드로 전송한다.

“1998 동계 올림픽 웹 사이트의 구조는 1996년 하계 올림픽 웹 사이트에서의 경험에서 발전한 것이다. 1996년에 우리가 수집한 서버 로그로부터 1998년 웹 사이트 설계의 중요한 통찰을 얻을 수 있었다. 우리는 대부분의 사용자가 기본적인 정보, 메달 순위, 최근의 결과, 현재 뉴스 등을 찾기 위해 너무나 많은 시간을 소비한다는 것을 알게 되었다. 클라이언트는 최소한 세 번 이상의 웹 서버 요청을 통해서야 결과 페이지에 도달할 수 있었다. 사이트의 뉴스, 사진, 스포츠 섹션 등에 대해서도 비슷한 브라우징 패턴을 보였다. 더 나아가, 한 클라이언트가 한 마지막 페이지에 도착하고 나면, 거기엔 다른 섹션에 있는 적절한 정보로 이동하는 직접 링크가 아무 것도 없었다. 이 계층적 탐색 순서 때문에, 중간에 탐색되는 페이지들은 가장 자주 접근되는 것들에 포함되었다.
1998 사이트의 주요 목표 중의 하나는 히트 수 감소였는데, 1996년의 웹 사이트 디자인과, 1998 사이트에서 제공되는 추가된 컨텐츠를 고려하여 예측하면 하루 2억 히트 이상을 기록하기 때문이었다. 따라서 우리는 페이지를 재설계하여 클라이언트가 관계된 정보들을 더 적은 수의 웹 페이지를 보면서 얻을 수 있도록 하였다. 1998 올림픽 게임 웹 사이트의 자세한 설명은 이전의 연구에서 얻을 수 있다.
가장 중요한 변화는 매일 새로운 홈페이지를 생성하고, 이전의 홈 페이지를 클라이언트들이 볼 수 있도록 하는 최상위의 탐색 레벨을 추가한 것이었다. 우리 예상으로는 개선된 페이지 설계로부터 3배 이상의 히트 수 감소를 얻을 수 있었다. 웹 서버 로그 분석에 의하면 25%의 사용자는 개선된 홈페이지에서는 그날의 홈페이지 하나만 보면 원하는 정보를 찾을 수 있었다.”
위에서 볼 수 있듯이 고성능 서버의 구현은 전체적인 시스템 설계, 로드밸런싱과 같은 구현 기법, 그리고 웹 사이트의 구축 과정에서의 튜닝 등 다양한 요소가 성공적으로 결합될 때 이루어질 수 있다.
필자가 번역한 전체 문서는 국내의 검색 엔진에서 ‘고성능 웹 사이트 검색 기법’이라는 문서를 찾아보기 바란다.
</IBM의 올림픽 사이트 관련>
　
　
2. 리눅스 로드 밸런싱 솔루션
(1) 리눅스 가상 서버 LVS (Linux Virtual Server)
리눅스 가상 서버 LVS 프로젝트의 홈페이지는 http://www.linuxvirtualserver.org이다. LVS(Linux Virtual Server)는 중국의 Wensong Zhang에 의해서 시작되었다. LVS의 기본적인 아이디어는 IBM에서 유래한 것이며, 애틀란타 올림픽과 시드니 올림픽과 같이 하루 동안 최대 접속이 10억번에 가까운 사이트의 구성을 위해 활용되었다. IBM은 이와 관련한 몇 개의 특허를 갖고 있다.
LVS 프로젝트는 그 이전부터 개발되어 오고 있던 HA Linux project를 활용하고 있으며 HA Linux 프로젝트는 mon, fake 등을 사용하고 있다. http://www.linux-ha.org 사이트에서 heartbeat 등의 패키지를 구할 수 있다. (HA Linux 프로젝트와 LVS 프로젝트, RedHat의 Piranha 패키지는 오픈 소스의 진화적인 발전 과정을 잘 보여준다고 생각한다. 이전의 상업적인 소프트웨어 개발 모델의 경우, 같은 이론이나 알고리즘을 사용하더라도 소스 코드의 활용이나 라이브러리화가 거의 이루어지지 못했는데, 오픈 소스 프로젝트에서는 다른 프로젝트의 소스 코드를 활용하는 것이 오히려 일반적이라고 할 수 있다.)
LVS에서 HA Linux 프로젝트는 Active-Passive 설정에서 상대편 서버가 정상적으로 동작하는지 판단하기 위해 사용되며, mon은 실제 서버 노드의 부하 수준을 판단하기 위해 사용된다.
이와 유사한 기본 아이디어를 갖고 있는 솔루션으로는 RedHat의 Piranha, Ultra Monkey, Turbo Linux의 Cluster 등이 있다. RedHat의 Piranha는 LVS를 바탕으로 재구성하고 기능을 추가한 패키지이다. Ultra Monkey의 경우 VA Linux에서 제시하고 있는 공개 솔루션으로서 LVS를 바탕으로 하고 있다. 터보 리눅스의 클러스터 서버도 기본 아이디어는 유사한데, 새로 구현된 코드로 구성되어 있다. 터보리눅스의 클러스터 서버는 설치되는 서버 노드의 수에 따라 비용을 지불해야 하는 상용 제품이다.
1) 로드밸런싱의 구조
로드밸런싱을 위한 구조는 다음과 같이 몇 가지 설정이 가능하다.
NAT
IP 터널링(Tunneling)
직접 라우팅(Direct Routing)
　
NAT는 사용자의 요청 패킷과 실제 서버의 응답 패킷이 모두 로드밸런서를 거치는 구조이다. 실제 서버에 다양한 OS를 사용할 수 있지만, 확장성이 좋지 못하다. IP 터널링은 로드밸런서와 실제 서버에 모두 IP 터널링을 처리할 수 있는 커널이 설치되어 있어야 한다. 시스템 설정은 유연하게 할 수 있다. 터널링을 위한 패킷변환 부하가 약간 증가한다. Direct Routing은 시스템 설정의 제약이 있으나, 높은 성능을 얻을 수 있다.
로드밸런싱 구조의 선택은 시스템 설정이 모두 끝난 다음 이루어지는 것이 아니라, 시스템의 용도에 따라 시스템 설정 이전에 선택해야 한다.
NAT
<시스템 구성>
　
　
<패킷의 변환>
패킷 변환은 다음과 같이 동작한다.
입력 패킷의 출발 주소와 도착주소가 다음과 같다고 하자.
SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80
로드밸런서는 실제 서버를 선택한다. 예를 들어 172.16.0.3:8000을 선택했다고 하면 패킷을 다음과 같이 변환하여 서버로 전송한다.
SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000
응답 패킷은 로드밸런서에 다음과 같이 돌아온다.
SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456
패킷은 원래의 가상 서버 주소에서 돌아오는 것처럼 보이기 위해 다시 다음과 같이 변환된다.
SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456
NAT는 패킷을 변환하여 실제 서버에 전달하고, 실제 서버에서 돌아오는 응답 패킷은 다시 NAT를 거쳐서 사용자에게 전달된다. NAT가 양방향 패킷에 대해서 모두 처리하므로 실제 서버에 임의의 OS를 사용할 수 있어서 응용 분야가 넓지만, 일반적으로 사용자의 요청 패킷에 비해서 실제 서버에서 돌아오는 응답 패킷의 크기가 훨씬 크기 때문에 (웹 서버의 경우, 사용자의 요청 패킷은 URL 요청으로 구성되지만, 실제 서버의 응답 패킷은 해당 URL에 대한 HTML 문서이다) NAT를 거쳐 가는 네트워크 패킷의 부하가 증가한다. 따라서 실제 서버가 10 노드 이하인 경우에만 NAT를 쓰는 것이 바람직하다.
NAT의 장점은 실제 서버에 임의의 OS를 사용할 수 있다는 것이고, 단점은 확장성이 떨어진다는 것이다.
IP Tunneling
<시스템 그림>
<패킷의 변환>
IP 터널링(Tunneling)은 로드밸런서가 사용자의 요청 패킷을 실제 서버에 전달하기 위해 다른 패킷 구조로 한겹 씌워서 실제 서버에 전달하면, 실제 서버가 새로운 패킷에서 사용자의 요청 패킷을 꺼내서 처리하는 방식이다. 따라서 IP 터널링은 실제 서버의 커널도 요청 패킷을 처리하기 위해 터널링을 지원해야만 하는 구조이다. 그러므로 리눅스로 전체 시스템을 설정하게 된다. 실제 서버의 응답 패킷은 이더넷 스위치를 거쳐서 바로 사용자에게 전달된다. 다음에 설명하는 직접 라우팅(Direct Routing) 보다 좋은 점은, 실제 서버가 IP 터널링을 지원하기만 하면 실제 서버는 지리적으로 멀리 떨어져 있어도 인터넷 상에서 연결되어 있기만 하면 된다는 것이다. 따라서 WAN 환경에서 로드밸런싱을 설정할 경우 IP 터널링을 고려할 수 있다.
IP 터널링의 장점은 확장성이 좋고(100 노드 정도까지), 실제 서버의 위치나 네트워크 연결의 제약이 적다는 것이며, 단점은 실제 서버에서 IP 터널링을 지원하도록 커널이 설정되어 있어야 한다는 것이다.
직접 라우팅(Direct Routing)
<시스템 그림>
직접 라우팅(Direct Routing)의 시스템 구조는 앞의 IP 터널링과 동일하다. 그렇지만, 로드밸런서와 실제 서버는 반드시 동일한 물리적 세그먼트에 존재해야 한다. 직접 라우팅은 이더넷의 브로드캐스팅을 사용하기 때문이다.
<패킷의 변환>
직접 라우팅은 로드밸런서와 실제 서버를 물리적으로 같은 네트워크 세그먼트에 위치시키고, 이 특성을 활용하여 IP 터널링처럼 패킷을 덧씌우는 것이 아니라, 단지 패킷의 MAC 어드레스를 목적지 주소로 변경시킨 다음 실제 서버로 전달하는 방식을 사용한다. 실제 서버는 IP 터널링의 패킷 변환 부하도 없으며, 실제 서버의 응답 패킷은 이더넷 스위치를 거쳐서 바로 사용자에게 전달된다.
직접 라우팅의 장점은 확장성이 좋고(100 노드 정도까지), IP 터널링을 처리하기 위한 오버헤드도 없다는 점과, 실제 서버에 특별한 설정이 필요하지 않다는 점이다. 단점은 로드 밸런서와 실제 서버가 물리적으로 같은 네트워크 세그먼트에 속해 있어야 한다는 점이다.
2) 스케줄링 알고리즘
또한 스케줄링을 위해 다음과 같은 몇 가지 알고리즘을 적용할 수 있다. 스케줄링 알고리즘은 앞의 로드밸런싱 구조에 달리 시스템 설정이 끝난 다음에도 알고리즘을 변경할 수 있다.
라운드-로빈(round-robin)
가중 라운드-로빈(weighted round-robin)
최소 연결(least connection)
가중 최소 연결(weighted least connection)
라운드-로빈 방식은 로드밸런서에 들어오는 요청 패킷들을 차례대로 실제 서버에 할당하는 방식이다. 이 방식에서 실제 서버의 현재 부하 상황 등은 고려되지 않는다. 단지 차례대로 할당할 뿐이다. 하지만, 이렇게 하더라도 로드밸런싱을 위해 이전에 사용되던 라운드-로빈 DNS 방식에 의해 서버를 할당하는 방식에 비해서는 우수한데, DNS의 경우는 한번 서버가 지정되면 해당 서버에 수많은 요청 패킷이 몰릴 수 있기 때문이다.
가중 라운드-로빈 방식은 기본적으로 라운드-로빈 방식인데, 각 서버에 서로 다른 가중치를 주어서 할당하는 방식이다. 이 방식을 사용해야 하는 경우는 실제 서버들이 CPU의 수와 성능, 메모리 용량 등 서로 다른 성능을 가지고 있어서, 각 서버를 동등하게 취급할 수 없는 경우이다.
최소 연결 방식은 실제 서버들 중에서 현재 가장 적은 수의 요청을 처리하고 있는 서버를 선택하여 요청 패킷을 할당하는 방식이다. 이 방식은 실제 서버의 현재 부하 상황을 동적으로 판단하여 요청을 처리하기 때문에, 앞의 두 방식에 비해서 동적으로 우수한 부하 분산 효과를 얻을 수 있다.
가중 최소 연결 방식은 기본적으로 최소 연결 방식인데, 가중 라운드-로빈 방식과 마찬가지로 각 서버에 서로 다른 가중치를 주어서 할당하는 방식이다.
3) 설정 예제
NAT의 경우 웹 서버를 위한 간단한 설정 예는 다음과 같다. 다음 설정은 모두 로드밸런서에서 설정한다.
로드밸런서가 패킷 매스커레이딩을 처리하도록 하기 위해 다음과 같이 설정한다.
echo 1 > /proc/sys/net/ipv4/ip_forward
ipchains -A forward -j MASQ -s 172.16.0.0/24 -d 0.0.0.0/0
그리고 웹 서버를 설정하는 경우, 가상 서버의 80 포트에 대해 스케줄링 알고리즘을 설정한다. wlc는 가중 최소 연결 방식을 나타낸다.
ipvsadm -A -t 202.103.106.5:80 -s wlc
그리고 로드밸런서에 실제 서버를 다음과 같이 추가한다.
ipvsadm -a -t 202.103.106.5:80 -R 172.16.0.2:80 -m
ipvsadm -a -t 202.103.106.5:80 -R 172.16.0.3:8000 -m -w 2
그러면 좀 더 자세히 설정을 알아보도록 하자.
패킷 매스커레이딩을 설정하는 것은 위에서 설정한 내용으로 충분하다.
다음으로, 스케줄링 알고리즘의 설정은 로드밸런서 설정 과정에서 ipvsadm에서 -s 옵션을 사용하여 설정한다. 다음 예제는 rr(round robin)으로 설정한 경우이고, wrr(weighted round robin), lc(least-connection), wlc(weighted least-connection) 옵션을 사용할 수 있다.
ipvsadm -A -t 207.175.44.110:80 -s rr
그 다음으로 실제 서버를 다음과 같이 설정한다.
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.1 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.2 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.3 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.4 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.5 -m
직접 라우팅 설정의 경우 다음과 같이 설정한다. 시스템이 사용하고 있는 주소는 172.26.20.xxx이고, 여기에서 로드밸런서의 주소는 111번, 실제 서버의 주소는 112번 이후, 그리고 가상 서버의 주소는 110번이다.
로드밸런서의 경우는 다음과 같이 설정한다.
ifconfig eth0 172.26.20.111 netmask 255.255.255.0 broadcast 172.26.20.255 up
route add -net 172.26.20.0 netmask 255.255.255.0 dev eth0
ifconfig eth0:0 172.26.20.110 netmask 255.255.255.255 broadcast 172.26.20.110 up
route add -host 172.26.20.110 dev eth0:0
echo 1 > /proc/sys/net/ipv4/ip_forward
ipvsadm -A -t 172.26.20.110:23 -s wlc
ipvsadm -a -t 172.26.20.110:23 -r 172.26.20.112 -g
실제 서버 1번에서 다음과 같이 설정한다. 다른 실제 서버의 경우 112를 113, 114 등으로 변경해야 한다.
ifconfig eth0 172.26.20.112 netmask 255.255.255.0 broadcast 172.26.20.255 up
route add -net 172.26.20.0 netmask 255.255.255.0 dev eth0
ifconfig lo:0 172.26.20.110 netmask 255.255.255.255 broadcast 172.26.20.110 up
route add -host 172.26.20.110 dev lo:0
또는 숨은(Hidden) 디바이스를 사용하여 다음과 같이 설정할 수도 있다.
로드밸런서에서 다음과 같이 설정한다.
echo 1 > /proc/sys/net/ipv4/ip_forward
ipvsadm -A -t 172.26.20.110:23 -s wlc
ipvsadm -a -t 172.26.20.110:23 -r 172.26.20.112 -g
그리고 실제 서버에서 다음과 같이 설정한다.
echo 1 > /proc/sys/net/ipv4/ip_forward
ifconfig lo:0 172.26.20.110 netmask 255.255.255.255 broadcast 172.26.20.110 up
route add -host 172.26.20.110 dev lo:0
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
LVS를 직접 사용하는 경우의 자세한 설명은 LVS Documentation (http://www.linuxvirtualserver.org/Documents.html)을 참조하기 바란다.
　
(2) 레드햇의 피라냐 (RedHat Piranha)
레드햇의 피라냐(piranha) 패키지는 LVS를 바탕으로 하여 재구성한 패키지로서 다음과 같은 세 개의 패키지로 구성되어 있다.
piranha 피라냐의 기본 패키지
piranha-docs 피라냐의 문서 패키지
piranha-gui 피라냐의 GUI 패키지
(piranha-gui 패키지의 경우, 피라냐 설정을 X 터미널을 통해서나 웹을 통해 원격으로 관리할 수 있도록 해 주는데, 이전의 패키지에서 기본 패스워드를 설정한 채로 출시되어 문제가 된 적이 있다. 현재는 piranha-gui 패키지를 선택한 다음 패스워드를 설정해 주는 프로그램인 piranha-passwd을 사용하여 원격 관리를 위한 패스워드를 설정하도록 하고 있다)
레드햇의 피라냐 패키지는 레드햇 6.x 버전의 경우는 기본 패키지에 포함되어 있었고, 7.x의 경우는 레드햇 ftp 사이트에서 구할 수 있다.
피라냐의 핵심은 로드밸런서 두 개 노드에서 동작하는 lvs와 pulse, 그리고 실제로 작업을 처리하는 실제 서버에서 동작하는 nanny 데몬으로 구성되어 있다.
lvs는 로드밸런서에서 사용자의 요청 패킷을 실제 서버에 분배하는 역할을 수행하며 pulse에 의해 실행된다. pulse는 로드밸런서가 정상적으로 동작하고 있는지 여부를 백업 로드밸런서가 알 수 있도록 하기 위해 사용된다. 그리고 nanny 데몬은 실제 서버와 로드밸런서에서 서로 다른 옵션을 사용하여 실행되는데, pulse에 의해 서버들의 상태를 모니터하기 위해 사용되는 데몬이다.
ntsysv에서 pulse 서비스를 선택함으로써 로드밸런서를 설정할 수 있다. 이렇게 설정함으로써, 로드밸런서가 매번 리부팅될 때마다 pulse 데몬이 실행되며, pulse 데몬이 실행되면 lvs 데몬과, fos 데몬이 실행되고, lvs 데몬은 nanny 데몬을 실행시킨다.
피라냐의 설정은 /etc/lvs.cf 설정 파일과, ipvsadm 관리 프로그램을 통해 이루어진다. 웹을 통해 설정할 수도 있지만, 웹을 통해 이와 같은 로드밸런싱 시스템을 설정하는 것 보다는 설정 파일을 사용하여 설정하는 것이 좋을 것 같다.
/etc/lvs.cf는 다음과 같은 세 부분으로 구성되어 있다.
Global Settings
Virtual Servers
Failover Services
다음은 sample.cf라는 샘플 화일에서 뽑은 것이다.
Global Settings부분은 다음과 같다.
service = lvs
primary = 207.175.44.150
backup = 207.175.44.196
backup_active = 1
heartbeat = 1
heartbeat_port = 1050
keepalive = 6
deadtime = 18
두 개의 로드밸런서 서버의 IP 주소를 설정하고, 백업 로드밸런서가 있으므로 backup_active를 1로 설정하며, heartbeat를 사용할 것이므로 heartbeat를 1로 설정한다.
Virtual Servers부분은 다음과 같다.
virtual server1 {
address = 207.175.44.252 eth0:1
active = 1
load_monitor = uptime
timeout = 5
reentry = 10
port = http
send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
scheduler = wlc
persistent = 60
pmask = 255.255.255.255
protocol = tcp
server Real1 {
address = 192.168.10.2
active = 1
weight = 1
}
server Real2 {
address = 192.168.10.3
active = 1
weight = 1
}
}
가상 서버의 주소는 207.175.44.252이고, 실제 서버의 주소는 192.168.10.2, 192.168.10.3 등이다. port=http는 port=80과 같이 쓸 수도 있다.
Failover Services부분은 다음과 같다.
failover ftp {
active = 0
address = 207.175.44.252 eth0:1
port = 21
send = "\n"
timeout = 10
start_cmd = "/etc/rc.d/init.d/inet start"
stop_cmd = "/etc/rc.d/init.d/inet stop"
}
위의 예는 ftp에 대한 failover 설정이며, 21번 포트에 대해 설정하고 있다.
ipvsadm은 LVS 패키지에서 바뀐 것이 거의 없다. 그리고 레드햇의 피라냐 패키지에서는 lvs.cf를 통해 시스템을 설정하도록 하고 있으므로, ipvsadm을 사용하지 않는 것이 바람직하다.
　
(3) 기타 상용 솔루션
1) Resonate
Resonate사의 홈페이지는 http://www.resonate.com이다. Resonate는 상용 로드 밸런싱 솔루션을 공급하는 회사로서 Resonate Central Dispatch와 Resonate Global Dispatch 등의 로드 밸런싱 솔루션을 제공한다.
Resonate Central Dispatch는 LAN 기반의 로드밸런싱 솔루션으로서, 기본적으로 LVS나 이를 바탕으로 한 RedHat Piranha 솔루션과 유사하다.
Resonate Global Dispatch는 WAN 기반의 로드밸런싱 솔루션으로서, 지역적으로 분산된 광역 시스템 설정을 위한 솔루션이다.
2) PolyServe underSTUDY
PolyServe사의 홈페이지는 http://www.polyserve.com이다. PolyServe는 underSTUDY라는 상용 로드 밸런싱 솔루션을 공급하는 회사이다. 현재는 LocalCluster enterprise라는 제품명으로 바뀌었다.
　
　
3. 리눅스 고가용성 솔루션
(1) 리눅스 고가용성 솔루션의 개요
1) 고가용성(High Availability) 클러스터란?
엔터프라이즈 컴퓨팅 환경에서 24 x 7 서비스란 1년에 시스템의 정지시간이 수분에서 1시간 이내여야만 한다. 이와 같은 무정지 서비스를 가능하게 해주는 클러스터를 고가용성(High Availability) 클러스터라고 한다.
고가용성 클러스터는 일반적으로 폴트 톨러런트(Fault Tolerant) 시스템과는 달리 보편적인 하드웨어와 네트웍 장비, 스토리지, UPS등으로 구성되며 서비스의 예정된 중단 혹은 불시의 중단에 의한 중단 시간(downtime)을 최소화하여 서비스 중단으로 인한 비용 손실을 최소화하도록 구성된다.
두대의 시스템이 Active-active (각각의 노드가 각각 서비스를 수행) 혹은 Hot-standby(한 노드가 서비스를 수행하고 다른 노드가 standby 상태로 대기) 형태로 구성되며 서비스중에 문제가 발생하거나(unplanned outages) 혹은 서비스 업그레이드 등을 위한 예고된 시스템 정지(planned outages)시 정지된 서버에서 가동되던 서비스가 나머지 노드로 fail-over 하도록 구성된다.
2) 고가용성(High Availability)
로드밸런싱 클러스터는 기본적으로 성능을 높이기 위한 클러스터이다. 그러나 여기서도 서비스 노드가 정상적으로 동작하지 않는 경우 해당 노드를 제외함으로써 전체적인 서비스를 계속하도록 한다.
반면에 로드 밸런서의 경우 하나의 서버의 오동작으로 인해 전체 시스템의 서비스 중단을 일으킬 수 있으므로, 이 경우에 대해 로드 밸런서를 중복시켜 문제를 해결할 수 있다.
로드 밸런서 두 개가 모두 오동작 하는 경우에 대해 이론적으로는 다른 서비스 노드들이 로드 밸런서의 역할을 이어받아 하도록 설정할 수 있으나, 실제 서비스 상황에서 이런 설정은 불필요한 경우가 대부분이다. RAID 스토리지의 경우에도 하나의 디스크의 오류에 대해서 고려하는 것과 마찬가지이다.
　
(2) Kimberlite/Convolo 클러스터
미국의 Mission Critical Linux 사에서 Active-Passive HA 솔루션을 두 가지 버전으로 제공하고 있다. Kimberlite는 소스가 공개되어 있는 GPL 버전이고, Convolo는 상용 버전이다. 이 회사의 홈 페이지는 http://www.missioncriticallinux.com이며, GPL 버전인 Kimberlite는 http://oss.missioncriticallinux.com/projects/Kimberlite 에서 받을 수 있다.
이들 클러스터는 데이타베이스 백엔드 등과 같이 저장 장치를 공유하는 경우에 적합하다. 예를 들어 MySQL, Oracle, NFS 등에 대해서 HA 솔루션을 제공하고자 하는 경우이다.
1) 하드웨어 설정
다른 클러스터와 마찬가지로, Kimberlite 클러스터의 경우에도 다음 그림과 같이 기본적인 시스템 설정이 중요하다. 기본적인 시스템 설정이 구성된 다음에 소프트웨어를 설치하고 소프트웨어적인 설정을 하게 된다.
두 서버 노드는 시스템의 상태를 저장하기 위해 quorum이라는 공유 디스크 파티션을 사용하고, 상대방의 상태를 검사하기 위해 이더넷, 시리얼 라인을 모두 사용한다.
　
2) 소프트웨어 설정
Kimberlite 패키지를 http://oss.missioncriticallinux.com/projects/Kimberlite/download.php에서 다운로드한 경우, Kimberlite 패키지는 소스 코드의 형태로만 배포되므로, 직접 빌드를 해야 한다. 빌드를 하기 위해서는 먼저 http://www.swig.org에서 swig 패키지를 받아서 설치해야 한다. (swig은 simplified wrapper and interface generator의 약어이다) swig 홈페이지의 다운로드 페이지를 보면 여러 버전이 있는데, stable release를 설치해야 한다. 압축을 풀고, ./configure, make, make install 과정을 거쳐서 swig을 설치한다. swig이 설치되고 나면 Kimberlite 패키지의 압축을 풀고, ./configure를 실행한 다음 make 하고, make install 하면 설치가 끝난다. 쉽게 설치가 될 수도 있고, 그렇지 않을 수도 있다. swig1.1p5와 Kimberlite-1.1.0을 받아서 빌드했다면 잘 설치될 것이다. Kimberlite는 /opt/cluster에 설치된다.
위의 그림과 같이 시스템을 설정하고, 소프트웨어를 설치하고 나면, Kimberlite 패키지를 설정하여 사용할 수 있다.
클러스터의 설정은 member_config 프로그램을 사용하여 이루어진다. 이 프로그램은 사용자가 어떤 정보를 입력해야 하는지 자세히 설명하고 있으므로, 쉽게 설정할 수 있을 것이다.
설정 내용을 간단히 요약하자면, 파워 스위치를 포함하고 있는지 여부, 클러스터 멤버의 이름, 상대편 시스템의 상태를 검사하기 위해 시리얼, 이더넷 등의 heartbeat를 몇 가지 사용할 것인지, 두 개의 quorum 파티션을 위한 raw 디바이스의 이름, 파워 스위치가 연결된 시리얼 라인 등이며, 먼저 자신의 시스템의 설정을 입력한 다음, 상대방 시스템의 설정을 입력해야 한다.
한 노드에서 member_config의 실행이 끝나고 나면, 다른 노드에서도 member_config을 실행시켜 주어야 한다.
새로운 노드에서 member_config을 실행하기 전에, 새로운 노드에서 다음과 같은 명령을 실행시켜 준다.
# /opt/cluster/bin/clu_config --init=/dev/raw/raw1
그리고 나서 새로운 노드에 대해서도 자신의 설정과 상대방의 설정을 순서를 바꾸어 입력해 준다.
이렇게 해서 모든 설정이 끝나고 나면, 다음 명령을 사용하여 클러스터를 실행한다.
# /etc/rc.d/init.d/cluster start
다음으로는 클러스터의 관리를 위해서 사용할 수 있는 명령들을 정리해 보도록 하자. 이들 명령은 모두 /opt/cluster/bin에서 찾을 수 있다.
diskutil : quorum 파티션의 설정 상태를 볼 수 있다.
pswitch : 파워 스위치의 설정 상태를 볼 수 있다.
cluadmin : 명령 방식으로 HA 클러스터를 관리할 수 있는 도구이다. 이 명령에서 지원하는 기능은, 서비스의 추가, 변경, 삭제, 그리고 서비스의 활성화/비활성화, 클러스터와 서비스의 상태 보기, 클러스터 데이타베이스의 백업과 복구 등이다.
cluadmin을 실행시키면, 다음과 같은 프롬프트를 볼 수 있다.
cluadmin>
이 프롬프트에서 help 명령을 사용함으로써 도움말을 볼 수 있으며, clear는 화면을 지우는 명령, exit는 프로그램을 종료하는 명령이다.
cluster에 대한 명령과 service에 대한 명령은 각각 cluster와 service 명령으로 시작하며, 다음과 같은 명령들이 있다.
cluster status 클러스터의 상태를 보여준다.
monitor 클러스터의 상태를 5초 간격으로 보여준다.
loglevel 데몬에 대해 로그를 어떤 수준으로 남길 것인지 지정한다.
reload 데몬들이 변경된 클러스터 설정 화일을 다시 읽도록 한다.
name 클러스터의 이름을 변경한다.
backup 클러스터 설정 데이터베이스를 백업 파일에 저장한다
restore 클러스터 설정 데이터베이스를 백업 파일에서 읽어들여 복구한다.
saveas 클러스터 설정 데이터베이스를 지정한 파일에 저장한다.
restorefrom 클러스터 설정 데이터베이스를 지정한 파일에서 읽어들여 복구한다.
Service add 클러스터 데이터베이스에 클러스터 서비스를 추가한다.
modify 지정된 서비스에 대한 자원이나 속성 등을 변경한다.
show state 모든 서비스 또는 지정한 서비스의 현재 상태를 보여준다.
show config 지정한 서비스의 현재의 설정을 보여준다.
disable 지정한 서비스를 중단한다.
enable 지정한 서비스를 시작한다.
delete 지정한 서비스를 클러스터 설정 데이터베이스에서 삭제한다.
웹을 통해 시스템 설정을 모니터하거나, 변경할 수도 있는데, GPL 버전인 Kimberlite의 경우는 시스템 설정의 모니터 기능만 제공한다. /opt/cluster/clumon 디렉토리를 웹 서버에서 참조할 수 있는 디렉토리로 옮기고, 이 디렉토리의 clumon.cgi 프로그램을 사용하여 시스템 설정을 모니터할 수 있다. 상용 버전인 Convolo의 경우는 웹을 통해 시스템 설정을 변경할 수도 있다.
현재 Kimberlite 패키지에서 기본적으로 사용할 수 있는 서비스는 Oracle, MySQL, NFS, Apache, IBM DB2 등이다. 예제 디렉토리인 /opt/cluster/doc/services/examples에서 Oracle과 MySQL을 위한 설정 파일을 볼 수 있으며, 다른 서비스에 대해서는 다음 문서를 참조할 수 있다. 오라클의 경우는 /opt/cluster/doc/services/examples/oracle/oracle 파일을 /etc/rc.d/init.d에 서비스로 등록하여 사용하면 되고, MySQL의 경우는 /opt/cluster/doc/services/examples/mysql.server를 서비스로 등록하여 사용하면 된다.
Kimberlite 패키지의 설정을 위한 가장 충실한 문서는 Kimberlite 패키지 안의 doc 디렉토리의 HTML 문서이다. 자세한 내용은 이 문서를 참조하기 바란다.
　
(3) OPS (Oracle Parallel Server)
1) 오라클 병렬 서버 OPS
오라클은 1998년 가을, 오라클 8 버전을 리눅스로 포팅한 제품을 발표한 이래, 오라클 8i, 오라클 8i Release2 등의 제품에 대해 리눅스 버전을 꾸준히 공급하고 있다. 오라클의 리눅스 버전은 리눅스 커널과 glibc 라이브러리 버전에만 의존하므로, 호환성은 좋은 편이다.
(오라클의 리눅스 버전은 다른 유닉스 환경으로 포팅하는 작업에 비해 짧은 시간에 이루어졌다고 실제 작업의 담당자가 인터뷰에서 밝힌 바 있다. 그리고, 현재 오라클에서 리눅스 버전을 지원하기 위한 인력도 100명을 넘어섰다고 한다. 또한, 오라클 내부에서는 인텔 리눅스 버전 뿐만 아니라, 다른 아키텍처, 즉 Compaq Alpha, Sun Sparc 등의 아키텍처에서 동작하는 리눅스를 위한 오라클 버전도 사용중이라고 한다. 그리고, 인텔에서 발표할 Itanium (IA-64) 64bit CPU를 위해서도 리눅스와 윈도우 64에서 동작하는 오라클의 베타 버전을 http://technet.oracle.com에서 얻을 수 있다. 그러나 이 오라클 베타 버전은 너무 오래된 Itanium 버전의 베타 리눅스 배포판을 대상으로 했기 때문에, 최근의 리눅스 베타 버전에는 설치되지 않았다.)
그리고 가장 최근의 Oracle 8i Release 3(Oracle 8.1.7)의 경우는 오라클 병렬 서버(OPS, Oracle Parallel Server)를 포함하고 있다. 국내 시장에서는 유닉스 시장에서 특히 오라클의 시장 점유율이 높은데(시장이 작기 때문에 1위 제품에 비해 다른 제품에 대해서 기술 지원이 충분히 이루어지지 못하기 때문인 것 같다), 앞에서 설명한 Kimberlite 클러스터나 OPS를 사용하면 상대적으로 저렴한 가격에 다른 상용 유닉스 제품에 못지 않은 가용성을 제공할 수 있다.
OPS를 사용하여 백엔드 데이타베이스를 Active-Active HA 클러스터의 형태로 구축할 수 있다. 물론 OPS를 사용하는 경우 두 대의 컴퓨터에 대해서 뿐만 아니라, 세 대 이상의 컴퓨터에 대해서도 HA 클러스터의 구축이 가능하다. Active-Passive 설정에 비해서 두 서버를 모두 서비스에 사용할 수 있다는 장점이 있으나, 두 서버 모두 오라클 엔터프라이즈 라이센스가 필요하며(Active-Passive 설정의 경우는 라이센스 하나로 충분하다), Active-Passive 설정에 비해 두배까지의 성능을 얻기는 어렵기 때문에, 앞의 설정에 비해 반드시 더 좋은 가격대 성능비를 제공한다고 말하기는 어렵다.
그림에서 보는 것처럼 오라클 병렬 서버는 분산 락 매니저(Distributed Lock Manager, DLM) 소프트웨어가 중요한 역할을 수행하며, 디스크를 공유하는 구조로 되어 있다.
오라클의 http://technet.oracle.com에서 OPS를 검색함으로써 자세한 OPS 관련 자료들을 구할 수 있다.
2) OPS의 설치
http://technet.oracle.com/software/products/oracle8i/software_index.htm 에서 Oracle 8i R3의 개발용 버전을 얻을 수 있으며, 설치 가이드도 얻을 수 있다.
오라클의 OPS는 디스크 공유 구조로 설계되어 있으며, 따라서 시스템의 기본적인 하드웨어 구성은 앞에서 설명한 Kimberlite 클러스터와 유사하다. OPS는 두 개 이상의 서버와, 이들 서버에서 모두 공유하고 있는 디스크 장치로 구성된다.
OPS를 설치하기 위해서는 공유 디스크에 노드 모니터를 위한 raw 디바이스를 설정해야 한다. 리눅스에서 raw 디바이스의 설정은 raw 명령을 사용하여 하드디스크 파티션에 대해 일종의 링크를 생성하는 방법으로 이루어진다. 그리고 watchdog 서버를 설정해야 하며, rsh과 rcp를 위해 /etc/hosts.equiv 파일을 설정하여 서버 노드 사이에서 패스워드 검사 없이 다른 노드에서 명령을 실행할 수 있도록 해야 한다.
오라클 설치과정에서 root.sh을 실행하는 과정이 있는데, OPS 설치 과정에서 각 서버 노드에서 이 스크립트를 실행해 주어야 한다.
OPS의 설치를 위해서는 오라클 설치 프로그램에서 Enterprise Edition을 선택하고, 설치 타입은 Custom을 선택하며(Typical에서는 OPS를 선택할 수 없다), Available Products에서 Oracle Parallel Server를 선택하여 설치한다. 설치 과정에서 OPS에 참여하는 원격 노드들의 노드 이름을 입력해 주어야 한다.
설치가 끝나고 나면, OPS에 참여하는 각 서버 노드에서 OCMS(Oracle Cluster Management Software)를 실행시켜 주어야 하며, 그 다음으로 설치 프로그램을 실행시킨 서버에서 dbassist와 netca를 실행시켜 데이터베이스와 네트워크를 설정한다.
* 오라클 병렬 서버 OPS는 오라클 8i Release 3에 포함되어 있지만, 별도의 라이센스를 요구하는 패키지이므로, technet에서 다운로드 받아서 사용하는 것은 개발 및 테스트용에 한정된다.
　
(4) SteelEye
SteelEye사의 홈페이지는 http://www.steeleye.com이다. 리눅스, 유닉스, 윈도우 NT 등의 OS에서 동작하는 LifeKeeper 솔루션을 공급하고 있다. LifeKeeper 솔루션은 AT&T에 합병되었다가 다시 분리된 NCR에서 파생된 솔루션으로서, 고가용성(High Availability. 99.9%의 가용성, 1년에 8.8시간 미만의 다운 타임)를 넘어서 Fault Resilience (99.99%의 가용성, 1년에 53분 미만의 다운 타임)을 보장한다고 말한다.
　
LifeKeeper 솔루션은 여러 노드로 구성된 시스템에서 가용성을 보장하기 위한 failover 기능을 다양한 시스템 연결 모델에 대해서 제공하고 있다. LifeKeeper 솔루션도 TCP, TTY, 공유 디스크 등 다양한 연결을 사용하여 상대 서버가 살아 있는지 계속 확인하며, N+1 설정에서 특정 서비스에 대한 자신의 상대 서버가 정상적으로 동작하지 않는 경우 해당 서비스에 대해서 서비스를 이전받아서 계속 서비스하는 구조이다. 자세한 내용은 LifeKeeper for Linux 페이지를 참조하기 바란다.
또한 LifeKeeper 솔루션은 MySQL, Informix, Oracle, Sendmail, Apache, Print 서비스에 대해서 recovery kit을 제공하고 있다.
SteelEye사의 홈페이지에서 특히 LifeKeeper Tutorial의 슬라이드를 보면 LifeKeeper에 대해 잘 설명하고 있으므로 참조하기 바란다.
필자의 판단으로는 Mission Critical Linux에서 제공하는 Kimberlite/Convolo 클러스터에 비해 SteelEye의 솔루션이 더 많은 기능을 제공하는 솔루션임은 분명하다. 그렇지만, Mission Critical Linux의 솔루션으로 충분한 응용에 대해서는 Mission Critical Linux의 솔루션이 더 가볍고 깨끗한 솔루션이라는 생각이다. 물론 비용 측면에서도 상대적으로 저렴하고, GPL 버전을 사용할 수도 있다. 두 제품 모두 훌륭하지만, 사용 목적에 따라서 선택해야 할 것이라고 생각한다.
　
　
4. 프로세스 마이그레이션
2장에서 살펴본 로드밸런싱은 사용자의 요청을 적절히 분산시켜 줌으로써 여러 서버 노드에 부하를 분산시키는 기법이다. 따라서 사용자의 요청이 빈번하며, 각 요청이 오래 실행되지 않는 응용의 경우에 바람직하다. 그러나, 사용자의 요청이 그렇게 많지 않고, 각 요청이 상대적으로 오래 실행되는 경우, 특정 노드에만 여러 프로세스가 실행되고 있을 때, 이를 다른 노드로 옮김으로써 로드밸런싱을 이룰 수 있다.
(1) 프로세스 마이그레이션 개요
프로세스 마이그레이션은 한 컴퓨터에서 너무 많은 작업이 실행중일 때, 로드 밸런싱을 위해 프로세스를 현재 많은 작업을 실행하고 있지 않은 다른 컴퓨터로 이동시키는 기법이다. 즉, 프로세스를 정적으로 처리하지 않고, 사용자의 요청에 따라 동적으로 할당할 뿐만 아니라, 프로세스가 실행 중에 다른 서버로 이동할 수 있다. 2장에서 살펴본 로드밸런싱 기법은 사용자의 요청을 처리하기 위한 프로세스를 어떤 서버에서 실행할지 결정하고 나면 실행이 끝날 때까지 해당 서버에서 프로세스가 실행되는 것에 비해서, 프로세스 마이그레이션에서는 프로세스가 실행 중에 다른 서버로 이동하는 것이기 때문에 더 많은 기술적인 제약을 갖는다. 특히 프로세스가 이동할 때 현재 열려있는 파일이나 소켓등에 대해서 어떻게 처리할 것인가 하는 문제가 중요하다.
프로세스 마이그레이션을 위해서는 기본적으로 각 서버 노드가 파일 시스템 등 외부 환경에 대해 동일한 인터페이스를 제공해야 한다. 즉 서버 노드의 투명성을 제공해야 한다. 그 다음으로 프로세스가 마이그레이션될 때 프로세스 상태를 어떤 서버가 관리할 것인가의 문제가 있다. 프로세스 마이그레이션의 구현은 커널 수준 또는 사용자 수준에서 이루어질 수 있으며, 관리 방식도 중앙 집중식과 , 분산 제어 방식으로 구분된다. 현재 MOSIX, Condor, Sprite 등의 프로젝트가 있다.
　
(2) MOSIX
MOSIX 프로젝트의 홈페이지는 http://www.mosix.cs.huji.ac.il/ 이다. MOSIX의 소스코드의 저작권은 GPL로 명시되어 있다. 이스라엘의 헤브루 대학에서 계속 연구되어 왔으며, 리눅스 버전은 버전 0부터 시작된 이 프로젝트의 버전 7이라고 한다. (홈페이지의 정보에 따르면 첫번째 버전은 PDP-11 상에서 1977년부터 1979년까지 개발되었다.) MOSIX의 적당한 응용 분야는 CPU 위주의 작업으로서 실행 시간이 긴 프로세스들로 구성된 작업에 적당하다.
MOSIX의 프로세스 마이그레이션은 커널 패치가 필수적이며, ReiserFS, GFS 등과 같이 동작할 수 있다. GFS와 함께 사용할 때, MOSIX는 파일 I/O를 마이그레이션된 노드로 함께 이동시킬 수 있다.
현재 리눅스 버전에서 활발히 개발되고 있는 MOSIX는 커널 2.2.19에 대해 안정적인 버전이 있으며, 커널 2.4.3에 대해서 개발 버전이 나와 있는 상태이다.
1) MOSIX의 설치
MOSIX를 설치하기 위해서는 패키지를 받아서 풀고, README 파일에 따라서 설치하면 된다. 매뉴얼 파일은 manuals.tar, 사용자 프로그램은 user.tar 파일에 들어 있다.
MOSIX의 클러스터 설정은 모든 노드가 동일하다. 수동으로 클러스터의 각 노드에 모두 설치할 수도 있고, 한 노드에 설치한 다음 클러스터의 모든 노드를 똑같이 복사해 주는 프로그램들을 사용할 수도 있다. 2.4.3 커널을 위한 개발 버전을 설치하는 경우, 먼저 일반 배포판을 설치하고, 2.4.3 커널의 소스 코드를 풀어서 여기에 MOSIX 패치를 적용한다. (배포판에 들어있는 소스 코드는 자체적인 패치를 너무 많이 포함하고 있기 때문에 MOSIX 패치가 잘 적용되기 힘들다) 패치를 적용한 다음에 빌드하는데, 레드햇 7.0의 경우는 들어있는 gcc 2.96을 사용하지 말고 kgcc를 사용해서 빌드하도록 한다.
커널을 빌드해서 설치하여 MOSIX 커널이 실행되도록 하고, user.tar의 사용자 프로그램을 설치하고 나면, mosix.init을 /etc/rc.d/init.d에 복사하고, 실행 레벨에 따라서 mosix.init을 실행하도록 다음과 같이 링크를 만들어 준다.
MOSIX의 시작을 위한 링크 :
ln -s /etc/rc.d/init.d/mosix /etc/rc.d/rc3.d/S95mosix
ln -s /etc/rc.d/init.d/mosix /etc/rc.d/rc5.d/S95mosix
MOSIX의 종료를 위한 링크 :
ln -s /etc/rc.d/init.d/mosix /etc/rc.d/rc0.d/K05mosix
ln -s /etc/rc.d/init.d/mosix /etc/rc.d/rc1.d/K05mosix
ln -s /etc/rc.d/init.d/mosix /etc/rc.d/rc6.d/K05mosix
이와 같이 MOSIX를 설치하고 나면 클러스터는 부하가 많이 걸린 노드에 대해서 프로세스를 다른 노드로 마이그레이션 한다.
이 때 중요한 시스템 데몬에 대해서는 프로세스 마이그레이션을 막아 주어야 한다. 이를 위해 /etc/inittab에서 데몬을 실행하는 경우에 "/bin/mosrun -h"를 앞에 붙여 준다. 예를 들어 "/etc/rc.d/rc 3"를 "/bin/mosrun -h /etc/rc.d/rc 3"으로 바꿔준다. rc.sysinit, update, shutdown 등에 대해서도 마찬가지이다.
　
(3) Scyld
scyld는 Beowulf 클러스터를 처음 만들어낸 Donald Becker (수많은 리눅스용 이더넷 드라이버의 개발자이기도 하다)가 Beowulf의 뒤를 이어 새로 내어 놓은 클러스터이다. (Scyld사에는 최근에 레드햇의 Robert Young이 경영진에 참여했다.) 홈페이지는 http://www.scyld.com이다. Scyld의 저작권은 GPL로 명시되어 있다. scyld에서도 MOSIX와 마찬가지로 프로세스 마이그레이션이 중요한 역할을 담당한다.
Scyld Beowulf 클러스터는 실제 작업을 처리하는 서버 노드들과, 이들을 관리하는 마스터 노드로 구성되어 있으며, 패키지의 핵심은 BProc(Beowulf Distributed Process Space)이다. 작업 프로세스는 실제 서버 노드에서 실행되면서도, 마스터 노드에서 프로세스 정보를 관리할 수 있도록 한다. 또한 다른 노드로 마이그레이션이 가능하다. 이를 처리하기 위해 마스터 노드에서 bpmaster 데몬이 동작하며, 실제 서버 노드에서 bpslave 데몬이 동작한다.
　
1) Scyld의 설치
Scyld는 CD의 형태로 판매된다. http://www.linuxcentral.com에서 주문할 수 있다. ftp를 통해서 받을 수도 있는데, http://www.scyld.com/page/products/beowulf/download.html에서 RPM과 SRPM 패키지들에 대한 링크를 찾을 수 있다.
README 파일을 보면 Scyld에 들어있는 패키지들 중에서 어떤 패키지들에 대해 수정이 이루어졌으며, 어떤 패키지들이 추가되었는지를 볼 수 있다.
추가된 패키지들은 bproc, beoboot, beompi, beosetup, beostatus, beowulf-doc, perf, netdiag, mpi-mandel, mpprun, tachyon, libbeostat, npr 등이다. 그리고 고성능 계산을 위한 패키지로서 scalapack, parpack, mpiblacs, atlas, hpl, octave, NAMD 등의 패키지를 포함하고 있다.
Scyld의 설치를 위해서는 CD 형태의 패키지를 구입하여 시스템에 처음부터 설치하거나, 레드햇 6.2 호환의 리눅스 운영체제를 설치한 다음, RPM 파일들을 다운로드하여 설치하면 된다.
　
　
5. 맺음말
로드밸런싱은 높은 가격대 성능비를 얻기 위한 다양한 클러스터 시스템 설정에서 실제로 높은 성능을 얻기 위해 매우 중요한 부분이다. 행렬의 분할에 의한 계산과 같은 정형화된 문제에 대해서는 굳이 로드밸런싱을 고려하지 않고도 문제를 해결할 수 있지만, 수많은 사용자에게 웹 서비스나 메일 서비스를 제공하기 위한 대규모 서버의 경우에는 2장에서 설명한 로드밸런싱 기법을 사용하면 여러 서버에 부하를 분배시켜서 높은 성능을 얻을 수 있다. 이와 같은 클러스터 설정에서 서버의 수가 늘어남에 따라서 일부 서버에서 에러가 발생할 확률이 증가하는데, 일부 서버의 에러에도 불구하고 전체적인 시스템의 서비스를 계속 제공하기 위해서 3장에서는 고가용성 설정에 대해 설명하였다. 그리고 4장에서는 2장과 같이 각 프로세스가 짧은 시간동안 실행되는 것이 아니라 상당히 긴 시간 동안 실행되는 경우, 특정 노드에 프로세스가 몰려서 성능을 향상시키지 못하는 것을 방지하기 위한 프로세스 마이그레이션 기법에 대해 설명하였다.
클러스터라는 말은 여러가지 시스템 구성에 대해 사용되고 있는데, 이 글에서 다룬 내용은 그 중에서, 성능(웹서버) 클러스터, HA 클러스터, 마이그레이션 클러스터 등이다.계산용 클러스터와, 스토리지 클러스터에 대해서는 이 글에서 자세히 다루지 않았다.
여기서 설명한 내용 외에도, 실제 서버가 수십 대 이상일 때, 데이터베이스 서버가 한 대로 충분하지 않은 경우에 데이터베이스 서버를 여러 대 설치하고 그 중의 한 서버에 대해서만 업데이트를 처리하고, 나머지 서버들은 이 서버로부터 데이터베이스를 주기적으로 복사해서 사용하는 등의 설정 등 높은 성능을 얻기 위한 여러가지 기법을 활용할 수 있다.
리눅스원(주)에서는 이 글에서 언급된 로드밸런싱 솔루션, 고가용성 솔루션, 오라클의 OPS 등을 비롯한 많은 솔루션들을 실제 고객 사이트에서 구축하고 있으며, 이 글에서 언급하지 않은 계산용 클러스터, 저장장치 클러스터 등에 대해서도 연구, 개발, 판매하고 있다. 이들 솔루션에 대한 기술 지원에 대해서는 회사로 연락해 주시길 부탁드린다. (연락처: 02) 3488-9800)
　
필자:
심마로
연락처 : maro@linuxone.co.kr
리눅스원(주) 연구원, 서울대학교 컴퓨터공학부 박사과정.
관심 분야 : 데이타베이스, 병렬처리, 운영체제, 컴퓨터 구조 등.
현재 생물정보공학(bioinformatics)을 위한 클러스터 기술 연구 개발 중.