Blog

왜 Bitnami Trac 인가?

설치 후 바로쓰기가 가능한 패키지가 여럿 있다. 이번에 검토한 것만 꼽아보자면,

• CollabNet Subversion Edge

• Visual SVN Server

• Bitnami Trac

운영체제를 윈도우로 정해놓았기 때문에 리눅스용 패키지는 전혀 고려하지 않았다. 이 중에서 Bitnami를 고른 이유는 간단하다. 편리하게 최적화해놓은 패키지일수록 커스터마이징하기가 더 어렵기 때문에 순수한 APM 패키지에 가까운 Bitnami 가 낙점이었다. Bitnami Subversion 도 있지만 Trac 을 정식으로 쓰진 않더라도 일단 달아두면 웹에서 이런저런 자료를 접근하기 편리할 것이라 생각했다.

Bitnami Trac 설치

우선 로컬에 설치된 IIS (윈도우용 웹 서버)를 정지시켰다. 아파치가 기본 웹 서버 포트 80을 쓰고 IIS 가 포트 8080을 쓰는 방식을 취할 생각이다.

Windows 용 Bitnami Trac 0.12-0을 설치했다. 설치 경로는 "F:\Build Workspace\" 이다. 설치 후의 폴더 구조는 다음과 같다.

• "F:\Build Workspace\"

• "F:\Build Workspace\Bitnami Trac Stack"

• "F:\Build Workspace\Bitnami Trac Stack projects"

• "F:\Build Workspace\Repository"

SSL 지원

내부 망이라 SSL이 필요 없을지 모른다. 하지만 오래 걸리는 작업이 아님을 이전 경험으로 알아서 오랜만에 몸 좀 풀겸 SSL 기능부터 넣었다. APM은 오랜만에 만지는 터라.

BitNami Trac Stack\apache2\conf\httpd.conf 파일을 열어서 mod_ssl.so의 주석을 해제한다.

LoadModule ssl_module modules/mod_ssl.so

BitNami Trac Stack\apache2\conf\extra\httpd-ssl.conf 파일을 열어서 SSLCertificateFile 및 SSLCertificateKeyFile 값을 다음과 같이 바꾸었다.

SSLCertificateFile "F:/Build Workspace/BitNami Trac Stack/apache2/certs/server.pem"

SSLCertificateKeyFile "F:/Build Workspace/BitNami Trac Stack/apache2/certs/server.pem"

원래는 인증서 파일을 직접 생성해야 하지만 이래저래 귀찮아서 Visual SVN Server 에 있는 파일을 가져다 썼다. 불친절한진 모르겠지만 인터넷 검색하면 인증서 만드는 방법은 잘 나와 있다.

이렇게 작업을 마친 후 다시 httpd.conf 로 돌아와 아래 줄의 주석을 풀었다.

Include conf/extra/httpd-ssl.conf

저장소 폴더 구조 변경과 Trac 프로젝트 설정

Binami Trac 이 설치 때 만드는 저장소 폴더 구조는 확장을 고려하지 않는다. Repository 폴더 안에 프로젝트 폴더를 따로 두는 게 이상적이다. 그러니까 "Repository\Initial Project\" 이런 식으로 말이다. 하지만 처음 설치하면 저장소 루트 디렉터리를 따로 두지 않고 덩그러니 Repository 폴더 안에 Initial Project 관련 파일이 풀어져 있다. 그러니까 루트 디렉터리는 없고 Initial Project만 있는 셈이다. 그래서 폴더 구조를 다음과 같이 바꾸었다.

• Repository\

• Repository\Initial Project\

• Repository\authz-windows

이로써 Repository 폴더 아래에 여러 개의 저장소를 두고 인증 정보는 authz-windows 파일로 공유하는 형태가 된다. 이렇게 폴더 경로를 바꾸고 나면 Trac도 설정을 바꾸어야 한다. resync 등의 명령으로 저장소 경로를 바꾸어야 하는데 어차피 예제로 만든 초기 프로젝트에 귀중한 데이터가 있는 것도 아니라서 "BitNami Trac Stack projects\Initial Project\" 폴더를 통째로 지우고 trac-admin initenv 명령으로 다시 프로젝트를 생성하기로 했다.

• "BitNami Trac Stack\use_trac.bat" 를 실행한다.

• "BitNami Trac Projects"로 경로를 바꾼다.

• trac-admin "Initial Project" initenv를 치고 요구하는 구성 값을 입력한다.

WebDAV 지원

WebDAV가 뭔지 설명하진 않겠다. 단지 "svn://어쩌구저쩌구"로 접속했다면, WebDAV 도입 후에는 "http://어쩌구저쩌구"로 접속이 가능해진다는 것만 알자. WebDAV 를 활성화하려면 httpd.conf 에서 주석을 하나 푼다.

Include conf/extra/httpd-dav.conf

그러고 나서 SVN 저장소의 루트 경로에 WebDAV로 접근하겠다고 명시해준다.

<Location /svn>
    DAV svn
    SVNParentPath "F:/Build Workspace/BitNami Trac Stack repository"

    # 중략
</Location>

윈도우 도메인 인증 지원

이번 설치 작업에서 제일 어려운 대목이었다. 그만큼 삽질을 많이 했지만 핵심만 요약한다.

SSPI 이용하기

정석이라 할만한 접근법은 SSPI 모듈을 이용하는 것이다. 이와 관련해 문서를 여럿 찾았다.

• Windows Authentication with Subversion on Windows

• Windows Domain Authentication

• Troubleshooting Windows Domain Authentication with Subversion

SSPI 모듈을 쓸 때 한가지 단점은 도메인 그룹별로 권한 제어하기가 힘들다는 점이다. 이에 대한 해결책이 어느 정도 나와 있지만 대부분 땜빵일 뿐이라 결국 SSPI 는 포기하기로 했다.

Visual SVN Server 이용하기

이래도 되는 건진 모르겠지만 Visual SVN Server에 윈도우 도메인 연동 기능이 있어서 그저 가져다 이용했다. 우선 인증 모듈을 "apache2\modules\"에 복사하고 httpd.conf 파일에 추가한다.

LoadModule authn_visualsvn_module modules/mod_authn_visualsvn.so
LoadModule authz_visualsvn_module modules/mod_authz_visualsvn.so

WebDAV 설정할 때 살펴봤던 그 코드에 인증 정보를 추가로 기입한다.

<Location /svn>
 # configure SVN
 DAV svn

 SVNListParentPath on
 SVNParentPath "F:/Build Workspace/Repository"

 # authentication
 AuthName "Subversion Repositories"
 AuthType VisualSVN
 AuthzVisualSVNAccessFile "F:/Build Workspace/Repository/authz-windows"
 AuthnVisualSVNBasic on
 AuthnVisualSVNIntegrated off
 AuthnVisualSVNUPN Off
 Require valid-user

</Location>

이 구성에서는 인증 및 권한 정보를 authz-windows 파일에 입력하기로 한다. 이 파일은 다음과 같이 생겨 먹었다.

# MyDomain\Developers
S-1-5-21-3412311087-3912312369-9541231218-13966=rw
# MyDomain\Managers
S-1-5-21-3412311087-3912311269-9232131218-13966=r

이 경우엔 실제 개발에 참가하지 않는 관리자가 실수로 파일을 변경하는 일이 없도록 읽기 권한만 부여한다. 이 구성파일에서 의아한 부분은 S-1 어쩌구저쩌구하는 문자일 텐데 이 값은 윈도우에서 사용자나 그룹을 구분하는 아이디 값이다. 명령 줄에서 whoami /all을 쳐 보면 내가 어떤 아이디 값을 보유했는지 알 수 있다.

IIS 연동

한 머신에 Apache와 IIS 두 개의 웹 서버를 사용하는 방법은 여러 가지이다. 머신에 네트워크 어댑터, 그러니까 랜 카드가 둘이라면 웹 서버를 각각의 랜 카드에 바운드시키는 게 제일 쉽다. 하지만 내부 개발용 머신이라면 랜 카드가 하나뿐일 가능성이 높고 지금이 딱 그런 경우라서 여기선 포트를 달리 하는 방법을 쓴다.

Apache에게 기본 웹 서버 포트인 80을 주고 IIS에는 대체 포트인 8080을 주었다. 이렇게 하면 IIS에 접속할 때 주소에 포트 번호 8080을 붙여야(예, http://localhost:8080/test.html) 한다. 하지만 프록시를 도입하면 이러한 내부 구조를 사용자에게 감추고 마치 웹 서버가 하나인 양 보여줄 수도 있다. 달리 말하면 8080을 떼고도 Apache가 운영하는 서비스에 접속이 가능해진다.

CruiseControl .NET Dashboard

어떻게 이렇게 하는지 실전 예제를 보며 알아보자. 빌드 서버인 CCNet에는 웹 대시보드가 있다. 닷넷 프레임워크로 만든 빌드 서버인 만큼 웹 대시보드도 ASP .NET, 그러니까 IIS 서버를 이용한다. 그러므로 http://localhost:8080/ccnet 이 기본 주소가 될 터이다. 하지만 Apache에 proxy 설정을 해주면 http://localhost/ccnet 으로 접속이 가능하다.

proxy 기능 활성화

BitNami Trac Stack\apache2\conf\httpd.conf 파일을 열어서 proxy 모듈의 주석을 해제한다.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so

httpd.conf 나 httpd.conf 가 Include 하는 다른 설정 파일에 CCNet으로 연결하는 프록시를 설정한다.

ProxyPassMatch (?i)^/CCNet(.*)$ balancer://iisccnet/\
ProxyPassReverse /ccnet balancer://iisccnet/

<Proxy balancer://iisccnet>
  BalancerMember http://plaintext0:8080/CCNet
</Proxy>

여기서 주목할 부분은 ProxyPass가 아닌 ProxyPassMatch를 사용한 점이다. Apache와 달리 IIS는 대소문자 구분을 하지 않기 때문에 CCNET이든 ccnet이든 CCNet에 대응하는 주소를 요청 받으면 IIS의 CCNet 응용프로그램으로 연결하게 했다.

마무리

이 외에 Trac 설정 등 다양한 주제가 있지만 우선 이만 마무리하기로 한다. 오늘은 기본 설치만 다루고 나머지는 좀더 경험을 쌓고 기회가 닿으면 썰을 풀어보던가 말던가.

• Author Details

Author Details

최 재훈

Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.

https://twitter.com/andromedarabbit

plaintext@andromedarabbit.net