'개발'에 해당되는 글 285건

MOD_SSL 모듈을 활성화 시켜준다.

$ sudo a2enmod ssl

VirtualHost 설정을 아래와 같이 추가한다.

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile # 인증서 경로 입력
        SSLCertificateKeyFile # 인증서 key 경로 입력
...
</VirtualHost>

Apache2를 재시작 한다. (또는 리로드)

$ service apache2 restart # 재시작
$ service apache2 reload # 리로드

443포트의 Listening을 확인한다.

$ netstat -nlp | grep 443

Nginx.conf 파일을 열어 아래와 같은 구문을 추가한다.

       
server {
    listen [::]:443;
    listen 443;
 
    ssl on;
    ssl_certificate # 인증서 경로 입력           
    ssl_certificate_key # 인증서 key 입력
    ssl_session_timeout  5m;
    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers on;
}

Nginx 재시작 or 리로드

$ service nginx restart # 재시작
$ service nginx reload # 또는 리로드

443포트가 Listening 되었는지 확인

$ netstat -nlp | grep 443

AWS에서 공식지원하는 ubuntu나 centos의 경우는, root계정 외에 ubuntu, centos 계정을 각각 세팅해서 설치가 되게 되는데,

AWS 중국에서 제공하는 OS라던지 공식지원하지 않는 OS를 설치한 경우에는, Key를 등록하고 SSH접속을 시도해도,

암호를 물어보는 경우가 있고, root 계정만 만들어서 나오는 경우가 있다.

최근 centOS를 깔았더니, root계정만 생성해서 발급되는 경우가 생겼고, 패스워드를 물어봐서 헤맸었기 때문에,

공식 지원하는 centOS처럼 centos 계정을 생성하고, 패스워드를 물어보지 않도록 변경해보았다.

1. 유저 생성하기 (ubuntu의 경우는 useradd -m 으로 계정을 생성해야 home폴더 아래에 계정 폴더가 생성됨)

$ useradd centos

2. private key를 복사 (root 계정으로)

$ mkdir -p /home/centos/.ssh
$ cp ~/.ssh/authorized_keys /home/centos/.ssh
$ chown -R centos.centos /home/centos/.ssh

3. sudo권한 지급 (Optional)

$ vi /etc/sudoers.d/**-cloud-init_users   # 파일명이 다를수도 있는데, 보통 하나만 들어있다.

가장 아랫줄에 아래와 같은 키워드를 추가해주자.

centos ALL=(ALL) NOPASSWD:ALL

$ visudo

마찬가지로 가장 아랫줄에 아래 키워드를 추가해준다.

centos ALL=(ALL) NOPASSWD:ALL

4. SSH 접속 시 패스워드 물어보지 않게 설정

$ vi /etc/ssh/sshd_config
PasswordAuthentication yes # 이 부분을 찾아서 no로 바꿔준다. 주석이 걸려있다면 주석 해제

5. root 계정으로 접근 막기 (Optional)

$ vi /etc/ssh/sshd_config
PermitRootLogin yes # 이 부분을 찾아서 no로 바꿔준다. 주석이 걸려있다면 주석 해제

6. sshd 데몬 재시작

$ service sshd restart

7. 생성한 계정의 패스워드가 만료되지 않도록 설정 (중요함)

$ chage -E -1 -M 99999 centos

이제 접속해보면 centos로 접근이 가능하고, sudo -i 로 root 권한 획득을 할 수 있으며, 최초에 패스워드도 물어보지 않도록 세팅이 되었다.

최근에 7번 항목을 진행을 안해서 EC2에 아예 접근이 불가능한 상황이 생겼어서, 7번항목을 추가함;; 다행히 remote command가 날라가서 머신은 유지한채로 살림. 7번은 필수로 진행을 해야한다.

1. Jenkins 다운로드

 - http://jenkins-ci.org/ 가자마자 download war 버튼이 있다.

2. Jenkins 설치

 - 설치랄게 별로 없고, tomcat의 webapps에 넣어주면 바로 접근이 가능해짐.

 - jetty가 내장되어 있기 때문에, 명령어만으로 바로 띄울 수도 있는 것 같지만, 플러그인 목록이 가끔 안보이는 문제 등 불안정한듯.. yum repo등록 시 설치하는 방법도 마찬가지..  

 - 그래서 톰캣에 올리는 것을 추천한다.

3. Jenkins 세팅 

 - 플러그인 먼저 설치해준다. (Jenkins관리 - 플러그인 관리)

 - Git Plugin, Gerrit Trigger Plugin을 설치한다. (재시작 없이 설치하기를 권장) 

(그냥 Gerrit Plugin이 있는데 Gerrit Trigger Plugin의 예전 버전이며, deprecated 된 플러그인이라고 한다. 실제로 오류를 뿜음)

 - Jenkins관리 - 시스템 설정에 가서 SCM (여기서는 git), Maven, Jdk에 대한 설정을 해준다.

4. Gerrit Trigger Plugin 설정 (Jenkins관리 - Gerrit Trigger) 

 - 좌측의 Add New Server버튼을 눌러서, Gerrit Server를 등록해준다. 

 - 아래와 같은 화면이 나오는데, 회사 정보는 삭제하였다. 

  - Frontend URL에 1번 포스팅에서 proxy설정을 마친, apache url을 입력해준다.

  - username, email은 jenkins전용 계정을 생성해서 등록하는 것을 추천한다. (Gerrit의 Verify Label에 찍히게 될 계정이다) 

  - 모두 입력 후, Test Connection을 눌러서 제대로 연결이 되는지 확인한다.

5. Item 추가 (구버전에서는 Job이라고 불렀었다.)

  - 좌측 상단의 새로운 Item버튼을 누르고, 내가 Maven을 주로 사용하므로 이름을 대충 지어주고, Maven Project를 선택한다.

6. Item Configuration  

  - 소스코드 관리 항목에서 git 부분에 gerrit에 생성되어 있는 repo의 ssh 경로를 적어준다.

  - credential도 gerrit에서의 인증정보와 동일하게 설정 해준다. 

  - 빌드유발 항목에 보면, gerrit event항목을 볼 수 있는데, Gerrit에서 특정 이벤트(Trigger On에서 지정한)가 발생하면 이 Item을 실행하도록 설정이 가능하다. 

  - 다른 항목은 각자 프로젝트 환경에 맞게 설정하고, Trigger on항목은 Patchset Created로 지정하여, 바로 테스트를 진행해보자.

  - 저장하고, 일부로 PatchSet을 생성해서 하나 올려보도록 하자.

  - 설정이 완료된, Item을 실행시킨다. 

  - Gerrit의 Verified Label에 verify 점수가 등록되어 있으면 성공! 

7. Item Detail Configuration

  - 6번과 같이 설정하는 경우 잘되는것처럼 보이지만, 새로 생성된 patchset에 대해서 빌드를 수행하지 않고,

기존에 올라가있는 소스에 대한 빌드를 수행한다.

  - 이럴 경우, 소스코드 관리 항목에서 고급을 눌러서 Refspec에 origin/$GERRIT_REFSPEC 라고 입력해주고,

Branches to build에는 $GERRIT_BRANCH라고 입력해준다.  

  - Additional Behaviours에서도 Strategy for choosing what to build항목에서 Gerrit Trigger를 명시해주어야 한다. 

  - 이렇게 하면, 올라간 Patchset에 대해서 빌드를 해준다..  

  - 저렇게 환경변수로 지정을 해두면, Trigger돌면서 환경변수에 해당하는 것을 알아서 찾아서 돌려준다.

  - 추가로, Additional Behaviours에서 Wipe out repository & force clone을 추가 해준다. (이게 없으면 전에껄 clone해옴)

8. 7번 문제에 대한 해결

  - Gerrit Trigger가 2.12.0으로 업데이트가 되었음.

  - Gerrit Trigger Configuration에 Build Current Patches Only 이런 옵션이 생겼다!!

  - 정말 가장 최근 PatchSet 찾아서 잘 verify한다..

  - 그리고 가장 중요한... 아래 화면... (좌측은 Plain으로 설정해서 Repository명 써야하고, 오른쪽 Branches는 Path로 바꾸어 주어야 **이 먹는다.. (이거 가지고 이틀 삽질함;;;) 

  - 참고로, 수동으로 돌리려면 Item자체를 실행하는 것이 아니라, Query and Trigger Gerrit Patches 메뉴에서 실행해주어야 한다.

(그래야 현재 Open되어 있는, PatchSet, Branch에 대해서 제대로 찾는 것 같다.) 

이후 세부 설정 및 복잡한 처리 프로세스에 대해서는 더 연구가 필요하며,

정리되는대로 하나씩 올려나갈 예정이다. 

기존에 주로 사용하던 SVN을 드러내고, Git으로 갈아타면서

코드 리뷰 시스템인 Gerrit을 사용해보기로 하였고, Gerrit을 사용하는 김에 Jenkins를 통해 verify하는 기능까지 연동해보기로 하였다.

일단 Gerrit을 사용하기 위해서는, 기본적으로 JDK가 필요하다.

1. JDK 설치

 - openJDK로 해도 되고, 소스 설치를 해도 됨. (이건 알아서...) 

2. Gerrit 다운로드 (버전 업이 자주되므로, 최신버전을 추천) 

 - http://gerrit-releases.storage.googleapis.com/index.html  

 - war파일 하나가 받아진다. 

3. Gerrit 설치

 - java -jar gerrit-2.9-1.war init -d /usr/local/gerrit-2.9.1/

 - 위 명령어를 실행하면, 뭔가 막 고르라고 나오는데, 대충 엔터를 치면 넘어가지만, 중요한 옵션들이 있다.  

DataBase Type, Authentification Method, Java Runtime은 신경써서 지정해주자. (잘못 지정해도 나중에 수정이 가능하긴함)

4. Apache  / mod_proxy 설치

 - Gerrit은 기본적으로 apache / nginx등의 proxy기능을 요구한다. (여기선 apache 기준으로 설명)

 - Apache는 2.2.xx 버전을 소스 컴파일로 설치할 것을 추천한다. (2.4.xx 버전은 apr-util등이 yum으로 설치 시에 버전이 낮다고 에러를 뿜는다.)

 - 설치 시 옵션은 아래 명령어 정도만 주면 된다. 

./configure --prefix=/usr/local/httpd-2.2.24 --enable-module=proxy  


 - 이렇게 설치 하면 보통은 apache/modules 폴더에 mod_proxy관련된 라이브러리 2개가 생겨야 하는데, 생기지 않는 경우 아래 링크를 참조한다. (라이브러리만 수동으로 컴파일하는 방법) 

http://blog.pointbre.com/2794/mod_proxy-%EC%84%A4%EC%B9%98-%EC%84%A4%EC%A0%95.html 

 - 이제 아파치 설정을 수정해보자.

 - httpd.conf에서 include httpd-vhosts.conf 항목을 주석 해제해주고, 포트도 80이 아닌 다른 포트로 적절히 바꾸어 준다.

(ex : Listen 8181) 

 - extra/httpd-vhosts.conf 에서 proxy설정을 해줌.

[httpd-vhosts.conf] 

NameVirtualHost *:8181 
<VirtualHost *:8181>
    ServerName localhost

    ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy> 

    
    <Location /login/ >    // login/ 경로에 대해서만 아래 인증 정보로 인증을 수행함.
        AuthType Basic
        AuthName "Gerrit Code Review"
        Require valid-user
        AuthUserFile /usr/local/gerrit-2.9.1/etc/passwords       // gerrit인증에 사용될 인증정보가 들어가 있는 파일
    </Location>

    AllowEncodedSlashes On      // 이 옵션이 없으면, Gerrit에서 / 가 들어간 경로로 진입할 때, permission이 없다고 나옴..

                                                    // 왜 안되지 하는데, 공식홈에 나와있었음;;
    # gerrit location
    ProxyPass / http://gerritHost:gerritPort nocanon     // nocanon은 없어도 잘 동작하지만, gerrit 공식 홈피 가이드에 나와있어서 추가
</VirtualHost> 

 - gerrit에도 proxy정보를 추가해주자. 

[gerrit.config]

[gerrit]
        basePath = git
        canonicalWebUrl = http://apacheHost:apachePort/
[database]
        type = h2
        database = db/ReviewDB
[index]
        type = LUCENE
[auth]
        type = HTTP
[container]
        user = root
        javaHome = /opt/jdk1.7.0_67/   
[sshd]
        listenAddress = *:29418
[httpd]
        listenUrl = proxy-http://gerritHost:gerritPort/
[cache]
        directory = cache 

 - htpasswd를 이용하여 Gerrit로그인에 사용될 사용자 계정을 등록해 주자.

/usr/local/apache2/htpasswd -c /usr/local/gerrit-2.9.1/etc/passwords ID PASSWORD

​

 - 브라우저에 http://apacheHost:apachePort/login/ 입력 후 위에 지정한 ID, PASSWORD로 로그인을 시도하면 로그인이 된다.

5. Verified Label 추가하기 (참고 : http://blog.bruin.sg/2013/04/how-to-edit-the-project-config-for-all-projects-in-gerrit/) 

 - Gerrit 2.9.1 버전 기준으로, Web UI상에서 Code Review Label밖에 없다. 하지만, jenkins에서 verify를 수행하게 하려면

Gerrit에서도 verify Label이 적용되어 있어야 함.

 - 로컬에서 git bash등으로 아래 명령어를 실행함. 

최초에 SVN 세팅 후, Commit을 한번하고 Show log 메뉴를 선택하면,

오프라인 모드로 전환하겠냐고 물어보는 경우가 있다.

이런 경우 SVN 서버가 설치된 서버에서 각 Repo경로로 이동하여 conf/authz 파일을 편집하여, 

아래와 같은 구문을 넣어주면 해결된다.

[/]

* = r 

기본적으로 svn에서 show history를 하는 방식은

anonymous 로써 history를 볼 수 있는 것이고, 계정 단위로는 따로 권한이 없다고 한다.

그렇다고 anonymous에 read권한을 줘버리면, 전혀 상관없는 사람이 repository url을 캐내서

checkout을 받아서 파일을 빼갈 수 있게 되버리는데,

이런 경우에 svnserve.conf 파일의 내용을 아래와 같이 고치고 anonymous에 read권한을 주면 해결이 된다.

* svnserve.conf

[general]

anon-access = none   # 기본 값이 read로 되어 있는데 이걸 none으로 바꿔서 anonymous는 아무것도 못하게 해버린다.

* authz

[/]

* = r

svnserve의 anon-access권한을 우선 시 하기 때문에, 이렇게 설정하면

실제로 모든 READ권한(checkout, show history)에 대해서 인증을 받게 된다.

생성되어 있는 repo경로에 hooks폴더에 들어가서 pre-commit.tmpl파일을 pre-commit파일로 만들어준다.

해당 파일을 vi등의 편집기로 열어 아래와 같이 수정한다.

#!/bin/sh
REPOS="$1"
TXN="$2"
# Make sure that the log message contains some text.
SVNLOOK=/usr/bin/svnlook
#$SVNLOOK log -t "$TXN" "$REPOS" | \
#  grep "[a-zA-Z0-9]" > /dev/null || exit 1
LOGMSG=$($SVNLOOK log -t "$TXN" "$REPOS" | grep [a-zA-Z0-9] | wc -c)
if [ "$LOGMSG" -lt 5 ]; then
    /bin/echo -n "(Empty commit log) & (length(log) < 5) is NOT ALLOWED" 1>&2
    exit 1
fi
# All checks passed, so allow the commit.
exit 0

필요에 따라 chmod 755옵션으로 실행 권한을 준다.

이후 커밋 시 빈 메시지로 입력하는 경우 에러가 발생함.

EC2 Instance를 생성하고나면, .pem 파일을 하나 다운받을 수 있게 되는데,

이게 putty에서는 인식을 하지 못한다.

그래서 putty-gen이라는 것을 사용해서 putty에서 사용할 수 있게 ppk파일로 만들어주어야 한다.

(putty-gen은 putty 다운로드 사이트에서 찾을 수 있다.)

실행하면 아래와 같은 화면이 나온다. 

SSH-2-RSA가 기본으로 선택되어 있으므로, 이것을 변경하지 않고 사용한다.

Load버튼을 눌러서, 아까 받은 .pem파일을 넣고, 패스워드 지정 (선택사항)한 후 활성화된 Save private Key버튼을 누르면 .ppk파일이 만들어진다.

이것을 이제 putty에 가서 등록을 하면된다.

아마존 공식홈에서 친절하게 설명이 되어 있어서, 이 링크를 참조했다.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

ELB를 Http형태로 세팅을 한 후라면, X-FORWARDED-FOR 헤더에서 찾으면 client ip를 쉽게 얻을 수 있는데,

웹소켓이라던지 기타 TCP 통신을 하는 TCP 형태로 세팅이 된 경우라면, ELB쪽에도 Proxy 세팅을 해야하고,

서버쪽에서도 추가로 Proxy Address를 받을 수 있도록 세팅을 해야 client ip를 얻어올 수가 있었다.

일단 해야 할 작업은 두 가지이므로 정리해본다.

1. ELB에 proxy protocol 활성화 하기

아마존 콘솔을 열고 아래의 명령어를 입력하면 완료된다.

aws elb create-load-balancer-policy --load-balancer-name my-load-balancer --policy-name EnableProxyProtocol --policy-type-name ProxyProtocolPolicyType --policy-attributes "AttributeName=ProxyProtocol,AttributeValue=true"

2. 서버 (이 포스팅에서는 Nginx를 사용하여 웹소켓을 사용함) 세팅

[nginx.conf]

server {
  listen  80  proxy_protocol; # 필수
  real_ip_header  proxy_protocol; # 필수

  location / {
    proxy_http_version  1.1; # 필요에 따라
    proxy_pass   http://127.0.0.1:8000/; # 필요에 따라
    proxy_set_header  Connection  $connection_upgrade; # 웹소켓을 사용한다면 필수
    proxy_set_header  Upgrade  $http_upgrade; # 웹소켓을 사용한다면 필수
    proxy_set_header  X-Forwarded-For  $proxy_protocol_addr;  # 필수
  }
}

기본 Nginx access log 설정이라면, 아마 기존과 동일한 ip가 확인이 될 건데, log_format을 살짝 변환하여 이를 해결할 수 있다.

[nginx.conf]

log_format forward_log '$proxy_protocol_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"' ;

access_log access.log forward_log # 기존 access_log 설정에 파라미터로 log_format 정의한걸 입력해주면 access_log에서도 확인을 해볼 수가 있다.

만약, nginx를 사용하지 않는경우라도, X-Forwarded-For 헤더에서 찾으면 원하는 client ip 정보를 얻을 수가 있다.