CentOS에서 Jenkins 설치하기

jenkins_logo

CentOS에서 Jenkins를 설치하기 위한 문서이다.

CentOS 6.4이고 Jenkins는 2013년 11월 17일 버전으로 한다.

젠킨스를 설치할 디렉토리를 설정하고 거기에 젠킨스 홈페이지인 http://jenkins-ci.org 에서 최신버전을 받아 넣는다. 현재 가장 최신 버전은 1.539 버전이다. 다운로드 받을려면 wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war 명령으로 war 파일을 받을 수 있다. 내 경우에는 /home/jenkins 디렉토리를 만들고 거기에 war 파일을 받아 넣었다.

톰캣의 환경설정을 한다. 내 경우에는 톰캣을 아파치와 연동해서 사용하고 있다.

톰캣의 서버 설정파일인 /etc/tomcat6/server.xml에 가서 다음의 내용르 추가한다.

<Host name="jenkins.도메인.com" appBase="/home/jenkins" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
 <Alias>jenkins.도메인.com</Alias>
 </Host>

난 Alias를 해놨기 때문에 Catalina 디렉토리의 jenkins.도메인.com 디렉토리의 ROOT.xml 파일을 수정해야했다. ROOT.xml 파일에는 다음의 내용을 넣는다.

<?xml version="1.0" encoding="UTF-8"?>
 <Context path="" docBase="" debug="1">
 </Context>

만약 Alias를 쓰지 않는다면 위의 server.xml 설정 파일 중 <Alias></Alias> 부분을 위의 내용으로 바꾸어주면 된다.

service tomcat6 restart 명령으로 톰캣을 재시작한다. 재시작하고 웹브라우저를 연다음 아까 설치한 http://jenkins.도메인.com:8080/jenkins 으로 접속해본다.

안된다…

방화벽의 8080 포트를 열어줘야한다. /etc/sysconfig/iptables 에서 8080 포트를 열어주고 service iptables restart 를 입력하여 방화벽을 재시작한다.

다시  http://jenkins.도메인.com:8080/jenkins 으로 접속하면 다음과 같은 화면이 뜬다.

jenkins_error

JENKINS_HOME이 설정되어 있지 않아 다른 디렉토리를 설정한다는 내용이다.

war 파일을 넣어놓은 디렉토리에 젠킨스 홈디렉토리롤 쓸 디렉토리를 추가한다. 내 경우에는 /home/jenkins/.jenkins 로 정했다.

그다음 /etc/profile에 다음의 내용을 추가한다.

export JENKINS_HOME=/home/jenkins/.jenkins

바로 적용을 위해서 source /etc/profile 을 입력한다. 내용이 적용되면 톰캣을 재시작한다.

다시 같은 위치로 들어가보면 다음처럼 젠킨스 사용 준비가 완료된다.

jenkins_ready

이제 젠킨스를 사용하면 된다.

SourceTree와 함께 Git과 git-flow 사용해보기

최근 회사에서 Subversion에서 Git으로 이전하고 있고 나 역시도 이제부터는 Git으로 옮겨가려는 생각이라 내 서버에 Git을 설치하고 사용해보기로 한다.

서버에는 yum으로 Git을 설치했다. 몇번의 시행착오끝에 방법을 알게되어 기록해놓는다.

서버에 저장소를 만들려면 다음의 순서를 따른다.

  1. 저장소 레포지토리를 만들 위치에 가서 mkdir로 디렉토리를 만든다. 일반적으로는 ‘프로젝트이름.git’을 사용하는듯하다.
  2. 만든 디렉토리롤 들어가서 ‘git init –bare’를 입력하여 초기화한다.

여기까지가 서버상의 설정이다. 물론 권한등을 더 설정해야할 수도 있다.

이제 SourceTree 어플리케이션을 사용해본다.

  1. SourceTree에서 저장소를 설정하여 연동한다.
  2. Git은 아무 파일도 없다면 master 브랜치가 생성되지 않는다고 한다. 로컬컴퓨터의 working copy 디렉토리에 touch 명령어로 빈파일을 하나 생성한다.
  3. SourceTree에 가서 commit을 한다.
  4. master 브랜치가 생성되을 것이므로 SourceTree의 git-flow 버튼을 눌러서 초기화하겠다는 창이 뜨면 OK를 눌러서 초기화한다.
  5. 이제 git-flow를 사용할 준비 완료.

몇번의 삽질 끝에 대략 이러한 과정을 거치면 된다는 것을 알았다. 나머지 레드마인과의 연동 등은 다음에 정리해보는 것으로.

맥 OSX에서 리눅스의 X-Window에 접속하는 방법

리눅스 서버에 이클립스를 설치해서 사용 중이다.

윈도우에서는 MobaXterm을 이용해서 접속하면 X-Window에 대한 처리를 알아서 다 해주기 때문에 신경쓸게 없었다.

맥에서도 리눅스 서버의 이클립스를 사용할 수 없을까 해서 동일하게 X-Window를 이용하려 했으나 역시나 되지 않았다. 여기저기서 찾아본 결과 다음의 과정을 거치면 사용할 수 있었다.

일단 X11 프로그램을 설치해야한다. 파인더를 열고 ‘응용 프로그램’에 있는 ‘유틸리티’ 폴더에 들어가 ‘X11’을 실행한다. 실행하면 아마 XQuartz라는 프로그램의 홈페이지인 http://xquartz.macosforge.org 로 이동한다. 이 프로그램은 맥에서 X11을 사용할 수 있는 프로그램이다.

이 프로그램을 설치하면 유틸리티 밑에 XQuartz라는 프로그램이 설치된다.

이 프로그램을 설치하고 다시 서버에 접속하여 이클립스를 실행했으나 역시나 실행되지 않았다.

다시 검색해서 다음과 같은 글을 찾았다.

http://mactips.dwhoard.com/mactips/x11-and-terminal/x11-forwarding

/etc/sshd_config 파일을 수정해야 한다는 내용이다. 링크의 내용대로 X11Forwarding 항목의 주석을 해제하고 yes로 변경해준다.

마지막으로 재부팅을 한번하고 iTerm2로 서버에 접속하여 이클립스를 실행해보면 내 맥에서 XQuartz가 자동으로 실행되며 X-Window로 접속된 이클립스가 실행된다. 만세!

CentOS에서 GIT 설치

회사의 형상관리시스템이 Subversion에서 GIT를 쓰기로 결정되어 GIT를 내 서버에 한번 설치해본다.

CentOS 6.4에서 yum으로 기본적인 패키지는 다 있을거란 가정하에 설치시작.

yum으로 설치하려 했으나 역시 공식 레포지토리에는 없다. 검색해보니 비공식 레포지토리를 이용해서 설치가 가능하긴하나 개인적으로 비공식 레포지토리는 EPEL을 제외하고는 좋아하지 않으므로 그냥 소스설치를 해보도록 한다. 페도라 EPEL에는 GIT가 있긴한데 그렇게 떙기진 않는다. ㅎㅎ

http://www.git-scm.com 에서 소스코드를 받아 압축을 푼다.

압축을 푼 후

make configure
 ./configure --prefix=/usr/local/git --with-openssl --with-libpcre --with-curl --with-expat --with-iconv --with-perl --with-python --with-zlib --with-tcltk
 make
 make install

하면 끝.

git라고 입력해보면 이제 git 명령이 잘 실행된다.

Zookeeper 설치

zookeeper회사 서버시스템에 적용 할 수 있나 알아보기 위해 Zookeeper를 테스트하기로 한다.

일단 아파치-주키퍼 사이트(http://zookeeper.apache.org/)에 들어가 다운로드 링크를 찾아 wget 으로 다운로드한다. 지금 이 포스팅을 하는 시점에서 가장 최신 버전은 3.4.5 버전이다.

압축을 풀면 나오는 디렉토리가 주키퍼의 프로그램 디렉토리이다.

일단 conf 디렉토리로 가서 zoo_sample.cfg 파일을 zoo.cfg 파일로 복사한다.

그리고 bin 디렉토리로 가서 ./zkServer.sh 명령으로 주키퍼를 실행한다.

실행하면 다음과 같은 화면이 출력된다.

JMX enabled by default
Using config: /backup/program/zookeeper-3.4.5/bin/../conf/zoo.cfg
Usage: ./zkServer.sh {start|start-foreground|stop|restart|status|upgrade|print-cmd}

CentOS의 service 와 마찬가지로 실행옵션을 주면서 실행할 수 있다.

./zkServer.sh start 를 입력했다.

JMX enabled by default
Using config: /backup/program/zookeeper-3.4.5/bin/../conf/zoo.cfg
Starting zookeeper … STARTED

시작되었다고 나왔지만 실제로 프로세스는 떠있지 않았다.

그래서 뭘까 생각해보다가 bin 디렉토리를 보았더니 zookeeper.out 파일이 생성되어 있었다. 이 파일의 내용에는,

nohup: failed to run command `/usr/share/java/bin/java’: 그런 파일이나 디렉터리가 없습니다

라고 되어있다.

아마 환경설정은 zkServer.sh 파일 안에 있을 것이므로 이 파일을 편집에서 java 라는 단어로 검색했으나 문제가 될만한 부분이 없었다. 하지만 보다보니 zkEnv.sh 를 실행하는 부분이 보인다. 파일명으로 보아 환경설정을 파는 파일이 이 파일 같으므로 다시 이 파일을 vi로 열어본다.

중간쯤 가다보면

if [ “$JAVA_HOME” != “” ]; then
JAVA=”$JAVA_HOME/bin/java”
else
JAVA=java
fi

이런 내용이 있다.

자바를 실행할 홈디렉토리를 설정하는 것 같다.

쉘로 나와서 echo $JAVA_HOME 을 입력해보니 /usr/share/java 이라고 뜬다. 그래서 결국은 zookeeper.out 파일에 /usr/share/java/bin/java 이런 경로가 없다고 나온 것이었다.

CentOS 6.4 에서는 java 명령은 사실 경로 설정이 없어도 상관이 없으며 굳이 경로를 넣고 싶다면 /usr/bin/java 로 실행하면 된다. (이 파일은 /etc/alternatives/java 의 심볼링링크이다.)

if [ “$JAVA_HOME” != “” ]; then
JAVA=”$JAVA_HOME/bin/java
else
JAVA=java
fi

이 부분을

if [ “$JAVA_HOME” != “” ]; then
# JAVA=”$JAVA_HOME/bin/java”
JAVA=/usr/bin/java
else
JAVA=java
fi

처럼 바꾸고 다시 ./zkServer.sh start 를 실행한다. 아무 문제 없이 STARTED 되었다고 나오고, 다시 ./zkServer.sh status 를 입력해보면

JMX enabled by default
Using config: /backup/program/zookeeper-3.4.5/bin/../conf/zoo.cfg
Mode: standalone

라고 나오면 실행 성공.

이제부터는 주키퍼를 실제로 사용해보도록 한다.

CentOS 에서 nginx 설치 #1

CentOS에서 nginx를 설치해본다.

nginx 사이트에서 레포지토리 파일을 받는다.

CentOS 6.4에서 yum으로 일단 편리하게 설치. php-fpm도 같이 설치한다.

php-fpm의 기본 설정 파일은 /etc/php-fpm.d 에 들어있다.

nginx 설정파일을 수정한다. php를 사용하기 위해 중요한 설정은 다음과 같다.

 

server {
listen 81;
server_name www.83rpm.com; 가상호스트가 쓸 도메인을 정의한다.

#charset koi8-r;
#access_log /var/log/nginx/log/host.access.log main;

location / {
# root /usr/share/nginx/html;
root /home/sadasd/public_html/test/; 루트 경로를 지정한다.
index index.php index.html index.htm;
}

#location / {
# proxy_pass_header Server;
# proxy_set_header Host $http_host;
# proxy_set_header X-Real-IP $remote_addr;
# proxy_set_header X-Scheme $scheme;
# proxy_pass http://127.0.0.1:80;
#} 이렇게 설정하면 프록시 설정하여 특정 도메인의 접속을 아파치로 넘길 수 있다.

#error_page 404 /404.html;

# redirect server error pages to the static page /50x.html
#
#error_page 500 502 503 504 /50x.html;
#location = /50x.html {
# root /usr/share/nginx/html;
#}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ .php$ {
# proxy_pass http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ .php$ {
root /home/asdasd/public_html/test/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
} PHP를 사용하기 위한 설정 root 경로를 주의한다.

# deny access to .htaccess files, if Apache’s document root
# concurs with nginx’s one
#
#location ~ /.ht {
# deny all;
#}
}

참고 URL : http://amuzr.blog.me/90169647032

시스템 코드페이지 변경

phpsysinfo를 업그레이드하고 나서 보니 Code Pages 부분 즉, 시스템코드페이지가 euc-kr로 나왔다.

왠만하면 서버의 모든 환경을 UTF-8로 맞추고 있는 실정이라 시스템코드페이지를 UTF-8로 변경하기로 결정.

/etc/sysconfig/i18n 파일을 열어서

LANG=”ko_KR.UTF-8″
SUPPORTED=”ko_KR.eucKR:ko_KR:ko”

이렇게 변경하고 저장한다.

완벽한 적용을 위해서 서버를 재부팅하면 완료.

드디어 서버에 하드디스크 추가

그동안 1년간 열심히 일해준 서버에 하드디스크를 추가해줬다.

하드디스크가 남기도하고 해서 어디다 쓸까 고민하다가 서버에 추가해주기로 결정. 그동안은 원격백업을 해왔는데 이젠 로컬백업을 할 수 있을 것 같다.

새로 추가할 웨스턴디지털의 500기가 하드디스크. 그린 모델인데 속도가 5400RPM으로 좀 느리다. 어차피 백업용도로 장착될 것이기 때문에 속도는 별로 상관이 없을듯하다.

내 서버는 HP DL120 G7 모델인데 하드디스크를 추가하려면 가이드가 필요했다. HP 정품 하드디스크 가이드는 따로 판매하지 않기 때문에 옥션에서 주문. 약 35000원 정도가 들었다. 정품인지 중국산인지는 모르겠으나 어쨌튼 장착해보니 잘 되었다.

토요일에 늦잠을 좀 자고 가산에 있는 LG IDC에 도착. 직원분과 함께 주민등록증을 맡기고 신분증을 받은 다음 서버가 있는 4층으로 향했다. 중간중간 출입증으로 보안장치를 세번 정도 통과해야했다. 물론 곳곳에 CCTV도 있다. 서버가 있는 곳은 신발을 벗고 실내화로 갈아신고 들어가야한다. 문을 열자마자 소음이 느껴졌다. 으…

케이지를 열고 들어가서 내 서버를 찾았다.

이게 내 서버. 사진에서는 가장 중간에 있다. 랙에서는 비교적 밑에 쪽에 위치했다. 아래 위로는 비슷한 대역대의 서버들이 모여있었고 대부분은 1U 크기의 서버들이었다.

일단 콘솔모니터와 키보드를 연결한 다음,서버에 셧다운 명령을 내리고 전원이 내려간 것을 확인했다. 그리고 서버의 블랭크 가이드를 빼고 그자리에 가져온 하드디스크를 밀어넣었다. 뭐 볼트 너트도 필요 없이 그냥 손으로 빼고 그냥 밀어넣으면 끝.

다시 전원을 올리고(전원 버튼을 못찾아서 해맸다. 전원불이 들어오는 램프가 버튼이었다. 이런…;;) 다시 루트로 로그인.

파티션 작업을 하려고하니 GPT 파티션 타입이라는 경고가 나왔다 아마 맥에서 외장하드로 쓰던 것이라 그런가보다. 파티션을 삭제하고 다시 파티션을 잡은 다음 포맷. 파티션은 하나로 잡았다. 사용가능한 용량은 총 460기가 정도. 포맷을 마치고 임시로 마운트하기 위해 백업디렉토리를 생성하고 마운트를 한번 해봤다. 그리고 테스트로 파일을 하나 카피해보니 잘된다.

부팅시 추가하기 위해 /etc/fstab에 하드디스크 UUID를 적고 마운트 디렉토리를 설정. 테스트하기 위해 한번 재부팅해본다. 마운트가 자동으로 잘되었으니 로그아웃한다.

콘솔모니터와 키보드를 다시 잘 정리하고 직원분께 간단하게 인사를 하고 나왔다.

백업용 쉘스크립트를 다시 작성해야하는데 언제 다 할래나…

리눅스에서 가상화 서버로 포트포워딩과 서비스 연결

좀더 빡세게 서버를 돌리기 위해 리눅스 서버 위에 윈도우 2008 서버를 가상화로 설치하여 사용 중이다.

문제는 이 리눅스 서버에는 이미 다양한 서버가 설치되어 있었는데 그중에는 웹서버도 포함되어 있었다. 또한 수십여개의 도메인도 연결되어 있었다. 기존에 사용하던 IP, 도메인 등은 그대로 둔채 특정 도메인이나 특정 포트만 가상화 서버로 연결해주려면 다음과 같이 한다.

<특정 포트만 가상화 서버로 포트포워딩하여 연결하고 싶은 경우>

iptables를 이용한다. 내 서버의 경우에는 윈도우 2008 가상화 서버에 192.168.122.95 라는 아이피가 부여되어 있었다.

<특정 도메인만 가상화 서버로 연결하고 싶은 경우>

이건 꽤 문제가 되는데 내 경우에는 HTTP 웹서비스를 담당하는 80번포트만 윈도우 서버에 따로 연결하고 싶었다.

아파치 서버의 conf 파일에서 Virtual Host를 하나 만들고 Server Name으로 원하는 도메인을 적은 다음과 같이 ProxyPass를 잡아준다.

ProxyPass / http://192.168.122.95/
ProxyPassReverse / http://192.168.122.95/

이렇게 하면 일단 해당 도메인으로 오는 요청을 리눅스 서버의 아파치 서버가 받은 다음 프록시 모듈을 이용해서 윈도우 서버로 통신을 넘겨준다.

krcert의 Castle JSP 설치 방법

KISA 한국인터넷진흥원의 인터넷침해대응센터에서는 Castle이라는 웹방화벽을 배포하고 있어서 설치해봤다. SQL 인젝션, 욕설 필터링 등등 좋은 기능이 많다.

이 소프트웨어는 PHP/JSP/ASP 3가지 버전으로 나와있어 자기 플랫폼에 맞는 버전으로 사용하면 된다. 내 서버의 경우에는 JSP와 PHP를 사용중인데 사실 PHP쪽은 잘 쓰지 않기도하고 JSP쪽으로 프로그래밍을 더 많이 즐기기 떄문에 JSP 버전으로 설치해보았다.

다운로드는 http://www.krcert.or.kr 에서 다운로드가 가능하다. 상단메뉴 중에 ‘웹보안서비스’에 ‘CASTLE’ 메뉴를 클릭하면 된다.

중요한 점 : 내가 해본 결과 이 페이지는 윈도우7 + 크롬에서는 잘 열리고 다운로드도 제대로 작동되었지만 맥 OSX 10.7 + Safari에서는 제대로 작동되지 않았다. 왜 다운로드가 안되나 한참 삽질했다.

다운로드하면 PHP/JSP/ASP 세가지 버전의 파일과 사용설명서, 설치설명서 등이 친절하게 들어있다. 사실 설치는 포함된 설치설명서 PDF 파일을 보고 그대로 하면 된다.

파일업로드 -> 자바 class 파일 컴파일 -> 기존 파일에 코드 삽입의 세단계로 이루어지는데 자바,  JSP와 서블릿을 조금이라도 해봤던 사람이라면 하나도 어렵지 않다.

문제는 다른 곳에 있었는데… 설치안내 문서에는 class 파일을 컴파일 할때 ‘javac *.java’를 실행하라고 나와있는데 이대로 했을 경우, EUC-KR 문자셋에 문제가 있다는 오류가 딱 100개 출력된다. 이 상태로 그냥 진행하면 작동은 되긴되나 나중에 방어 메시지가 한글이 모조리 깨지며 로그 파일의 한글도 모조리 깨지게 된다. java 파일을 열어봤으나 UTF-8로 제대로 저장되어 있었고 컴파일 명령도 제대로 내렸는데 왜 안됐을 까 한참 고민했는데 생각해보니 내 서버는 모든 환경을 UTF-8로 사용하고 있었다.

중요한 점 : 컴파일 할 때 ‘javac -encoding utf8 *.java’와 같이 -encoding 옵션으로 자기에게 맞는 문자셋을 지정해줘야한다. 정상적으로 컴파일이 되었다면 프롬프트에 아무런 메시지도 나타나지 않아야한다.

클래스 파일을 컴파일해서 넣고 진행했다. 이제서야 제대로 작동한다. install 화면을 진행하고 내 사이트의 헤더 파일에 프로그램 소스코드를 삽입한 후 작동테스트를 시작했다. 그런데 또 하나의 문제점 발견. 내 사이트에서는 예를 들어, a.jsp 파일에 form 양식이 있고 여기서 데이터를 입력 받은 다음 b.jsp 파일에 POST 형식으로 데이터를 넘기게 되어있었는데 a.jsp 파일에 캐슬 소스코드를 넣고 SQL 인젝션 테스트를 했더니 아무런 경고조치 없이 돌아가는 것이었다. 왜 이러나 고민하다가 b.jsp 파일에다가도 캐슬 소스코드를 넣었더니 그제서야 제대로 인젝션이 차단되었다.

중요한 점 : 데이터를 페이지에서 페이지로 이동시키며 처리하는 경우는 양쪽 모두에다가 캐슬 소스코드를 넣어줘야한다.

이렇게 설치하고 테스트해보면 SQL 인젝션을 잘 차단해주며 로그도 정상적으로 쌓인다.

 

사용해보니 몇가지 아쉬운 점은..

  1. 설치문서가 조금 단순하다. 좀더 다양한 상황에서 테스트해주시고 설치문서를 써주셧으면.
  2. 로그 파일이 저장되는 위치를 바꿀 수가 없다. 리눅스에서는 /var/log 디렉토리가 주로 로그파일 디렉토리로 많이 쓰이는데 castle은 로그파일이 무조건 캐슬 설치 디렉토리의 log 디렉토리에만 저장된다.
  3. 한 사이트마다 캐슬을 하나씩 설치해야한다. 캐슬 하나만 설치해서 여러사이트, 여러도메인에서 공유해서 사용할 수 있는 방법이 있으면 좋을 것 같다. 내 서버의 여러 사이트들에도 캐슬을 적용하고 싶었는데 한 사이트당 하나씩 설치해야하니 너무 부담스러워서 그만뒀다. 이렇게 설치해서 사용할 수 있는 방법이 있다면 설치문서에라도 좀 추가되길.
  4. iptables 같은 방화벽 소프트웨어와 연동해서 공격IP를 자동차단 할 수 있으면 더 좋을 것 같다. 웹프로그램의 특성상 시스템명령 수행이 좀 어렵긴하지만 가능하지 않을까? Runtime 클래스를 이용해도 될것 같고 아니면 나중에 C로 한번 만들어봐야할 것 같다.

하여튼 너무 좋은 프로그램 개발해주셔서 감사~ ^^ 혹시 나중에 krcert 관계자분이 이 글을 보게된다면 꼭 불편한 점과 아쉬운 점은 고쳐주셨으면 좋겠다.