프로그램/web server2012. 10. 14. 16:07

기본적으로 JSP는 JRE 상에서 동작하기 때문에 불가능 하다.
그렇기 때문에 일반적으로 isapi_redirect ISAPI 필터를 이용한다. 
이 방법은 IIS가 받은 요청을 Tomcat이 대신 처리하고 그에 대한 response를 전달하는 방식이다.

* 중요 : 실질적으로 해당 요청은 Tomcat 에서 처리한다. 즉 서버에 Tomcat 및 JRE 환경이 우선 구성되어 있어야 한다.

먼저 tomcat이 설치된 상태에서 isapi_redirect.msi를 다운 받아 설치 한다.
다운 로드 : http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15/isapi_redirect.msi

isapi_redirect.msi 설치 완료 후 Tomcat 이 설치되어있는 디렉토리의 conf 폴더에 있는 server.xml 파일을 열어 다음과 같이 맨 마지막줄의 앞에 1줄을 추가 한다.

아래 그림에서 보듯이 C:\inetPub\wwwroot 는 IIS를 설치하면 기본으로 구성되는 웹 폴더이다. 만약 웹 컨텐츠가 다른 곳으로 변경되어 있다면 해당 경로로 변경해줘야 한다.

uriworkermap.properties 파일 내용을 수정 한다.

isapi_redirect.msi가 설치된 폴더의 uriworkermap.properties 파일을 오픈

아래의 반전되어있는 부분의 3줄을 추가

isapi_redirector을 isapi필터에 등록
isapi_redirector을 isapi필터에 등록시키기 위해서 기본웹사이트의 속성을 클릭

isapi필터 tab을 선택 후 추가 버튼 클릭

필터 이름 : isapi redirector  을 입력하고, 실행파일에는 isapi_redirect.msi 설치폴더 아래 /bin폴더에 있는 isapi_redirect.dll을 등록한 후 확인 클릭

* isapi_redirect.dll 파일이 있는 경로

다음과 같이 isapi 필터의 상태에서 위쪽으로 녹색화살표를 확인 가능
이를 통해 isapi필터가 정상적으로 적용 확인
(만약 아래쪽으로 내려간 빨간색 화살표가 보인다면 iis를 재 시작 필요)

* windows 2003 일경우에는 아래 항목을 추가로 해 주어야 한다.

(windows 2000일 경우에는 생략.)
인터넷 정보 서비스 관리에서 웹 서비스 확장을 선택 마우스 오른쪽을 눌러 새 웹 서비스 확장 추가를 선택 

새 웹 서비스 확장 창에서 추가 버튼을 클릭

isapi_redirect.msi 설치폴더 아래 /bin폴더에 있는 isapi_redirect.dll을 등록한 후 열기를 클릭


확장 이름은 Jakarta 로 입력
확장 상태를 [허용됨]으로 설정 부분에 체크 를 한 다음 확인을 클릭

아래와 같이 jakarta 라는 웹 서비스 확장이 추가 된 것을 확인 할 수 있음

관련 문서
http://blogs.msdn.com/david.wang/archive/2005/10/11/How-does-JSP-work-on-IIS.aspx
http://tomcat.apache.org/connectors-doc/reference/iis.html
http://nextline.net/?inc=support&html=pds_view&no=183 (설치 문서 강추)

Posted by wrnly
프로그램/web server2012. 10. 12. 20:30

JDK + TOMCAT 설치

1. JDK 다운로드 및 설치
http://java.sun.com/javase/downloads/index.jsp
- JDK는 편할대로 설치 (난, C:\Java\jdk...)
- JRE는 기본 경로로 설치

2. Path 설정 (JAVA_HOME, PATH, CLASSPATH)
- [내컴퓨터 등록정보] - [고급] - [환경변수]
JAVA_HOME 으로 JDK설치한 디렉토리 설정 (난, C:\Java\jdk...)
PATH 앞에 JDK bin 디렉토리 추가 (난, ;%JAVA_HOME%\bin;)
CLASSPATH 로 현재 디렉토리 설정 ( .; )

3. TOMCAT 설치
http://tomcat.apache.org/
- 다운받고 원하는 폴더에 설치 (난, C:\tomcat)
- 기본포트인 8080 포트 http://localhost:8080 으로 접속하여 톰캣 구경

사용자 삽입 이미지



4. Path 설정 (CATALINA_HOME)
- [내컴퓨터 등록정보] - [고급] - [환경변수]
CATALINA_HOME 으로 톰캣 설치한 디렉토리 설정 (난, C:\tomcat)

5. uriworkermap.properties 파일과 workers.properties 파일 생성
- 톰캣이 설치된 디렉토리의 conf 디렉토리에 생성

** uriworkermap.properties 

/jsp/*=defworker
/jsp/*.jsp=defworker

/examples/*=defworker
/examples/*.jsp=defworker
/examples/servlet/*=defworker


** workers.properties 

workers.tomcat_home=C:\Tomcat6\

# workers.java_home should point to your Java installation. Normally
# you should have a bin and lib directories beneath it.
#
workers.java_home=C:\Program Files\Java\jre1.6.0_02\

# You should configure your environment slash... ps=\ on NT and / on UNIX
# and maybe something different elsewhere.
#
ps=\

# The workers that your plugins should create and work with
#
worker.list=defworker

#------ DEFAULT ajp13 WORKER DEFINITION ------------------------------
#---------------------------------------------------------------------
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to match.
#
worker.defworker.port=8009
worker.defworker.host=localhost
worker.defworker.type=ajp13


IIS + TOMCAT 연동

1. connector 다운로드
http://tomcat.apache.org/download-connectors.cgi 
 (최신버전의 binary releases 에서 isapi_redirect.dll 파일 다운로드)
- 톰캣이 설치된 폴더의 bin/win32/i386 디렉토리로 이동

2. ISAPI redirector 속성파일 설정
http://tomcat.apache.org/connectors-doc/reference/iis.html 참고하여 isapi_redirect.properties 속성 파일 생성
- isapi_redirect.dll 와 같은 디렉토리에 저장

3. iis 가상 디렉토리 생성
- 디렉토리명 : jakarta
- 컨텐츠 경로 : isapi_redirect.dll 파일이 있는 디렉토리

4. 기본 웹사이트에 ISAPI필터 설정
- 필터 이름 : 아무거나
- 실행파일 : isapi_redirect.dll 파일이 있는 디렉토리

5. 새 웹 서비스 확장 추가
- 확장 이름 : 아무거나 
- 파일 경로 : isapi_redirect.dll 파일이 있는 디렉토리

6. IIS 다시시작
- 제대로 연동이 된다면 ISAPI필터 상태가 위를 향한 초록색 화살표시가 나타난다.

사용자 삽입 이미지


7. 경로 테스트
- http://localhost/index.jsp (톰캣 구경)

Posted by wrnly
프로그램/web server2011. 9. 20. 22:40

웹 서버와 WAS는 비슷한 개념이라 그런지 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷이 확산될 당시만해도 웹 서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 WAS를 더 많이 사용하게 되었다. 이제는 사용자에 따라, 또는 상황에 따라 똑같은 제품이 웹서버로 불리기도 하고 WAS라고 불리기도 한다.

 두 개념 사이의 근본적이 차이점이 무엇인지 알아보자.

Web Server와 WAS의 정의

Web Server

• Web Client(웹 브라우저)에게 제공하는 콘텐츠를 제공하는 서버.

• 즉 정적인 HTML이나 jpeg 혹은 GIF 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저로 제공.

• 초창기만 해도 단순히 HTML이나 이미지만 제공되는 사이트가 많았다.

 

WAS (Web Application Server)

• 서버 단에서 애플리케이션을 동작할 수 있도록 지원.

• 일반적으로 container라는 용어로 쓰인다.

• 초창기에는 CGI, 그 이후에는 Servlet, JSP, ASP, PHP 등의 프로그램으로 사용되고 있다.

 

언제부턴가 웹이 다양한 형태의 프로그램들을 제공하기 시작했다. 최근에는 게시판이나 방명록 등 서버와 사용자가 상호 대화 할 수 있는 페이지로 제공한다. 이제 대부분의 웹서버들이 이러한 요구에 맞춰 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다. 단지 웹서버의 기능만을 수행하던 기존과는 달리 동적인 요구에 대응하기 위해 이에 적합한 형태로 변화한 것이다. 해당 제품의 웹 서버 유무를 구분할 때 제품의 기능 보다는 사용하는 기능에 초점을 맞춰 분류하게 된 시점이다. 즉 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 layer를 나누게 되었고 여기서 웹 서버와 WAS의 구분점이 생기게 된 것이다.

웹 서버와 WAS의 구성에 따른 분류

1. 기본적인 웹 사이트 환경

웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 WAS의 역할을 동시에 수행. 이런 구성은 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러 대의WAS를 통해 지원이 가능하다. 필요시 추가로 WAS를 증설하는 구조라고 볼 수 있다.

하지만, WAS가 정적인 데이터(HTML/image)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에, 최적화 측면에선 그다지 바람직하지 않다. 또한 정적 데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있다. 웹 애플리케이션의 수행으로 정적인 데이터에 영향을 줄 수 있어 사용자 요청이 증가할 경우 대처가 어려운 측면도 있다.그래서 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성시 활용의 가치가 높다.

 


2. 웹 서버와 WAS로 구성된 환경

 

웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 WAS가 처리한다.

사용자 요청에 대해서 정적 데이터인 html과 자바 스크립트 파일, CSS, image 등을 앞단의 웹 서버에 위치시켜 처리함으로써 WAS로 서비스 요청이 넘어가게 않게 한다. 더불어 그 가운데 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS까지 넘겨줌으로써 WAS는 웹 애플리케이션의 수행에 집중할 수 있다.

비용적인 측면 또한 중요하다. 웹 서버는 상대적으로 저렴한 제품이나 오픈 소스를 사용하면 전체를 WAS로 구성하는 것보다 비용적인 측면에서 효과가 크다. WAS의 경우 정적인 html이나 image 처리에 있어 상용 제품이 오픈 소스나 상대적으로 저렴한 웹 서버 보다 낮은 성능을 보이기도 한다. 이는 일반적인 웹 페이지보다 웹 애플리케이션을 동작시키는 곳에 더 최적화 되어 있다고 보면 된다. 웹 서버 단에서 처리할 것과 WAS에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 configuration을 통해 처리할 수 있다. 특정 확장자나 디렉토리 업무는 WAS로 넘기고 그렇지 않은 것은 웹 서버 단에서 처리한다.

이에 고려할 사항으로 개발 환경과 운영환경이 서로 다를 수 있다는 것이다. 즉 개발환경에서는 굳이 웹 서버와 WAS를 구분하지 않고, 운영 서버에서만 구분하는 경우 Context Root 밑에서의 html, 자바 스크립트, CSS, image 등의 디렉토리를 적절히 구분하는 것이 필요하다.


<리스트 1>은 아파치 웹 서버에 환경정보를 수정하여 WAS가 처리할 확장자를 지정하는 예제이다

5-jini7652

 

3. 이미지 서버를 별도로 두고 있는 환경

 점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 WAS를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다.

이런 환경들은 각 사이트의 특성을 파악하여 얼마든지 응용할 수 있다. 자신의 사이트에서 가장 많은 비중을 차지하거나, 트랜잭션을 차지하는 부분이 무엇인지 확인하고, 그렇게 구분된 콘텐츠를 적절히 배분하는 것이다. 바로 <그림 3>이 이미지가 많은 사이트에서 취할 수 있는 방법인 셈이다. 또는 특정 콘텐츠만 집중적인 요청을 받는 경우도 있다. 예를 들어 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, Reload 또한 빈번하게 일어나므로 특정시간 간격으로 html을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다.

이런 동적인 환경은 다양한 상황에 대처가 빠르다는 장점도 있지만, 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰인다는 단점도 있다. 관리상의 문제가 발생할 수도 있다. 환경을 구성하기 전에 충분한 검토가 성행돼야 한다.

 WAS단의 프로그램이 많은 비중을 차지하는 경우, presentation logic을 담당하는 프로그램과 business logic을 담당하는 프로그램을 구분하는 구성이다. 이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.

 

Web Server와 WAS의 구분

기능적으로만 본다면 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있지만 모두 웹 서버 혹은 WAS라고 부르는 것 보다는 어떤 기능을 수행하는지 따라, 즉 기능상의 분류를 통해 구분지어 사용해야 할 것이다.

 

 

참조

1. 월간 micro Software 2007년 3월호. P. 166~167 “웹 서버와 WAS(Web Application Server)

WAS(Web Application Server)?

was는 J2EE 스펙을 구현한 서버입니다. 그중에서 특히 주목해야할 건 jsp/servlet Container와 EJB Container로서의 기능입니다. 이중에서도 EJB Container로서의 역할에 비중이 크죠.

가장 많이 쓰이는 WAS는 BEA사의 Web Logic이며, 그밖에도 여러가지의 WAS가 있습니다. 참고로 tomcat 은 jsp/servlet Container의 기능은 구현했으나 EJB Container로서의 기능은 없습니다. 그래서 tomcat은 WAS가 아니라고 하는 분들도 있습니다.

application이라 함은 응용프로그램입니다.응용프로그램이란 어떤 목적을 위해 만들어진 프로그램입니다. word는 문서작성을 위한 목적을 가지고 만들어진 프로그램이며, 포토샵은 이미지 편집/작성을 목적으로 만들어진 프로그램입니다.

web application이란 web에서 어떤 목적을 처리할 목적으로 만들어진 프로그램을 총칭하는 말입니다. 대표적인 웹 어플리케이션으로는 게시판, 쇼핑몰 등이 있겠네요. 아 지금 이곳 지식iN도 웹 어플리케이션입니다. word와 포토샵을 웹으로 구현하면 그것도 웹 어플리케이션입니다만 일반 어플리케이션을 그 상태 그대로 웹에서 실행시킬 수는 없습니다. 미들웨어도 하나의 응용 프로그램이라고 볼 수 있습니다.  주요 기능으로는 각 응용 프로그램간의 연계이죠.

미들웨어로서의 WAS는 Web Server와 DB Server 사이에 존재하면서 웹 어플리케이션을 탑재하고 있습니다. 이 웹 어플리케이션의 주요 기능은 DB의 데이터를 사용자의 목적에 맞게 가공하여 web server를 통해 보여주는 것이죠.

그럼 왜 WAS를 사용하느냐? 한마디로 분산환경에서 사용합니다. 분산환경에서의 가장 큰 이슈는 트랜잭션 처리인데, 이 트랜잭션 처리를 아주 적은 비용으로 효과적으로 처리할 수 있게 해주는 것이 WAS입니다.

<참조>
http://belselios.tistory.com/entry/Web-Server-와-WASWeb-Application-Server비교

Posted by wrnly
프로그램/web server2011. 9. 20. 21:30

우선 크게 아파치, IIS, Iplanet 정도가 있다. 


1) 아파치(apache) LINUX 계열의 웹서버

 아파치는 쉽게 말하자면 가장 대중적인 웹서버로 무료이다 보니 많은 사람들이 사용하는

 웹서버 입니다. 아파치는 여러번의 패치를 거친 NSCA 서버에서 시작되어서 이름이 아파

 치가 되었죠(패치가 된 웹서버라는 뜻인데 붙여서 읽으면 발음이 apache가 된다군요 ;;)

 아파치의 가장 좋은 점은 소스코드까지 공짜로 얻을 수 있는 것 입니다.

 아파치는 자바 서블릿을 지원하고, 실시간 모니터링, 자체 부하테스트등 여러가지 기능을 

 제공 합니다.  무료인거에 비해 성능이 괜찮아서 여전히 대형  사이트들을 제외하곤  아파

 치를 많이 사용 합니다. 아파치는 대부분의 OS에서 구동이 가능합니다.

 아파치의 각 기능과 버전은 http://www.apache.org 에서 확인 가능 합니다.

 

2) IIS (Internet Information Server) Windows 계열의 웹서버

 IIS는 MS사에서 WINDOW전용 웹서버로 개발한 서버 입니다. 그래서 공짜라 하기는 머하

 나 XP시디가 있다면 IIS를 설치 할 수 있습니다.  특징이라면 검색 엔진 , 스트리밍 오디오,

 비디오 기능이 포함 되어 있습니다. 또한 예상되는 부하의 범위와 이에 대한 응답을 바탕

 으로 한 튜닝 기능도 포함되어 있습니다. 상업용 제품이라 여러가지 제약이 좀 따르는게

 문제이지만 Windows에서 만큼은 가장 잘 돌아가는 웹서버라고 하겠습니다.

 

3) Iplanet (Sun One Java Web Server)

 SUN사에서 개발한 Iplanet 웹서버는 주로 대형 사이트에서 사용하는 상용 웹서버 입니다.

 버전은 현재 7.0 버전까지 나왔으나 현 사이트에서는 주로 6.0 버전과 6.1 버전을 많이 사용

 하고 있습니다.

 Iplanet 웹서버는 http://www.sun.com 에서 다운로드 받아서 설치할 수 있습니다.

 하지만 공개 release 버전과 라이센스가 있는 버전과의 기능과 성능은 큰 차이가 있습니다.

 iplanet에서는 장점이라면 여러가지 기능 관리콘솔 제공 자체 jsp/servlet 엔진을 제공합니

 다. 대충 스펙을 보더라도 아파치나 IIS에 비해 월등하죠.. 그래서 대형 사이트에서 주로

 iplanet을 사용합니다.

 덧붙여 WAS(Web Application Server)라는 미들웨어가 있는데 이건 웹서버 뒷단에서

 J2EE나 J2SE같은 Jsp/Servlet을 처리해주는 역할을 해줍니다.




 

Posted by wrnly
프로그램/web server2011. 7. 25. 13:22

 

  1. 개요
  2. 시작하기에 앞서 필요한것들
          °
    2-1. 환결설정
          °
    2-2. 다운로드 받기
  3. 아파치 설치하기 (바이너리 인스톨)
  4. 설정
          ° 4-1. httpd.conf 파일
          ° 4-2. srm.conf 파일
          ° 4-3. access.conf 파일
          ° 4-4.
    CGI/SSI 의 설정
  5. 시동
          ° 5-1. 일반적인 작동 방법(Win NT 사용자)
          ° 5-2. 세부적인 작동 방법
          ° 5-3. 기타 (작업중)
  6. 종료
  7. 필자 한마디
  8. 부록 : Win32 for Apache 컴파일(작업중)

1. 개요

이 문서는 마이크로소프트 윈도우환경에서 어떻게 설치하고, 설정 및 운영하는지 설명하고 있다.

(경고: 아파치 Win32 버전은 아직 성능 등이 최적화 되어 있지않다. 그러므로, 최고의 성능을 원한다면 유닉스 플랫폼의 버전을 사용하기를 바란다. 현재 아파치 그룹에서 계속적으로 NT 퍼포먼스를 증대시키기

위하여 개발중이며 solaris,FreeBSD,Linux 와 같은 유닉스 플랫폼에서 작동하는
아파치를 윈도우상에서도 같은 성능을 낼수 있도록 계속적으로 노력할 것이다.)

현재 전세계적으로 볼때 다양한 서버제품군들이 유닉스에서 보다 좀더 편리한 환경을 제공하는 윈도우환경으로

많이 전환하고 있다. 이것은 어찌보면 피할수 없는 현실이다. 사용자들은 좀더 쉽고 배우기 쉬운것을
찾으려 하기 때문에 결국은 많은 환경들이 아쉽게도 유닉스에서 윈도우환경으로 바뀔것이다.
이에 발맞춰 아파치 그룹에서는 윈도우 웹서버의 시장을 많이 장악하고 있는 마이크로소프트에 대적할
만한 윈도우용 웹서버를 발표하였다. 물론 아직까지는 유닉스버전 만큼 안정적이지 못하다는 이유로
그리 많은 사용자층을 확보하고 있지는 못하지만 무료로 배포한다는 점과 유닉스버전의 뛰어난 성능등에
견주어 보면 윈도우용 아파치는 큰 잠재성을 가지고 있다. 지금 바로 윈도우용 아파치의 뛰어난 기능을
경험해 보기 바란다.

이곳에서 제공하는 문서들은 여러분들이 바이너리 윈도우 버전을 설치한것으로 가정하고 설명한다.
만약 아파치를 컴파일 하기 원한다면 문서아래의 부록을 참고하기 바란다.

이 문서는 아파치를 사랑하는 모든이들에게 도움을 줄 목적으로 작성되어졌다. 그러나 이 문서로
인해 발생하는 문제에 대해서는 작성자는 책임을 질수 없음을 밝힌다.

2. 시작하기에 앞서 필요한것들

아파치 1.3 은 Windows NT 4.0 하에서 작동할수 있도록 디자인 되었다. 바이너리로 제공되는 파일은 오직 인텔 프로세스 에서만 작동한다. 아파치는 Windows 95, Windows NT 3.5.1 에서도 작동할수 있을지도 모르지만, 이러한 환경에서는 테스트 되어 있지 않다.
아파치를 작동시키기 위해서는 TCP/IP 네트워킹이 반드시 설치되어 있어야 한다.
윈도우 95 환경하에서 아파치를 사용하는 유저라면 "Winsock 2" 를 업그레이드 하기를 권장하지만 꼭 필요한 것은 아니다.

주의: "Winsock 2" 는 아파치 1.3.7 이후버전에서는 꼭 필요하다.

"Winsock 2" 윈도우 95 버전은 이곳에서 다운로드 가능하다.

NT 4.0 에서 운영하려면 서비스팩 2 이상을 설치하기를 권장한다. (현재 서비스 팩은 4 까지 나와있기는 하지만 한글버전은 서비스팩 3 까지 나와있다. NT 4.0
을 운영하고 있는 사용자라면 보안적인 면에서도 반드시 서비스팩 3 를 설치하기를 바란다.)

아파치 웹서버의 최신버전은 http://www.apache.org 에서 정보를 얻을수도 있으며, 국내에서는 이곳을( http://www.apache.kr.net) 통하여 정보를 제공하고 있으므로, 국내 사용자들은
이곳을 통하여 다운받아가기를 바란다. [아파치 최신버전 받아 가기]

윈도우 버전을 다운로드 받기위해서는 확장명이 .exe 인것을 받아야 한다. 설치하고 운영하기 위한 것들이 모두 한 파일로 제공되어 지고 있다. 바이너리 말고도 여러분들이 직접 컴파일 할수 있도록 소스파일을 zip 으로도 제공하고 있다.(만약 .zip 파일이 없다면 소스파일은 .tar.gz 로
도 제공하니 참고하기 바란다.)

3. 아파치 설치하기 (바이너리 인스톨)

위 다운로드 사이트에서 다운받은 apache.exe 를 실행하자!! 그러면 아파치를 어디에다
설치할 것인지를 물어 볼 것이다. (
디폴트는 \Program Files\Apache Group\Apache 이지만
다른 디렉토리로 변경할 수 있다.)
시작 메뉴에 추가될 이름(디폴트는 Apache Web Server)과 인스톨 타입을 물어 볼 것이다.
"Typical" 옵션을 선택하면 소스코드를 제외한 모든것이 설치될 것이다. "Minimum" 옵션은 메뉴얼과 소스코드를 설치하지 않을것이며 소스코드를 설치하기를 원한다면 "Custom" 옵션을 선택하면 된다.

[이미 설치를 한번 한 경우]
인스톨하는 중에 아파치는 선택한 인스톨 디렉토리 안의 conf 디렉토리에 설정파일등을 조정할 것이다.
그러나 디렉토리 안에 이미 파일들이 존재한다면 덮어씌우기는 하지 않을 것이다. 대신 확장자가 .default 라는 이름으로 새로운 카피본을 만들어 넣을 것이다. 예를 들자면, conf\httpd.conf 파일이 이미 존재한다면 이 파일은 바뀌지 않을 것이며 새로 설치되는 파일이 conf\httpd.conf.default 라는 이름으로 설치될 것이다. 설치가 완료된 후에 한번 .default 라는 파일에 새로운 어떤것이 추가되었는지 한번 살펴보기를 바라며 또한 존재하는 configuration 파일을 필요하다면 업그레이드 하기를 권장한다.


또한 htdocs\index.html 의 파일을 이미 가지고 있다면 그것 또한 덮어씌우지는 않을 것이다. (index.html.default 파일은 인스톨 되지 않을 것이다) 이것이 말하는 바는 이미 아파치를 한번 인스톨 하였다 하여도 새로이 설치되는 파일은 겹쳐쓰기를 하지 않으므로 위험하지 않다는 얘기다. ( 그러나 인스톨 하기전에는
반드시 작동중인 아파치 서버를 중지시켜야 하며 인스톨이 끝마친 후에는 새로이 설치된 서버가 다시 시작될것이다.)

주의 : 혹, 오래된버전(1.3b6 이하)을 인스톨 하려는 사용자에게 : 위 사항은 1.3b7 이상의 사용자에게 적용되는 사항이다. 1.3b6 을 인스톨한다면 conf 디렉토리 안의 httpd.conf, access.conf,srm.conf 또는 mime.types 파일을 모두 덮어씌울것이며 또한 htdocs 디렉토리 안의 index.html 또한 덮어씌운다. 아파치 1.3b6 를 인스톨하려고 할 경우에는 이 파일들을 다른 곳으로 카피해 두기를 바란다.
필자는 이러한 오래된 버전을 설치하려고 하는 분들이 없을거라고 생각하지만 혹시나 이러한 버전을
사용하고자 하는 분들에게 정말 최신버전을 사용할 것을 당부하고 싶다. 보안적, 성능, 또는 기타 다른이유로 오래된 버전은 사용하지 않을것을 권장한다.

아파치 인스톨을 마친후에는 conf 디렉토리의 configuration 파일들(httpd.conf, srm.conf, access.conf)
을 설정해 주기를 바라며 이러한 파일들은 아파치가 작동하는데 있어서 중요한 역확을 한다.
사용하지 않는 기능들은 주석(#) 을 달아 작동치 않게 하고 필요한 기능만 사용토록 하자.


4. 설정

아파치는 conf 디렉토리 안의 파일에 의해 설정되어 지며 이 파일은 유닉스버전에서 사용하는 것과 같다.
그러나 윈도우용 아파치에서는 약간 달라진 옵션이 있다. 아파치의 모든 설정값등은 아파치 메뉴얼을 참고하기 바라며 또한 이 홈페이지의 메인페이지를 참고하기 바란다.

윈도우용 아파치에서 크게 달라진 점은 다음과 같다:

윈도우용 아파치는 멀티스레드(MultiThread)방식을 이용한다는 점이다. 이것은 큰 의미를 가지고 있다.
유닉스머신에서 작동하는 아파치와는 달리 단지 2개의 아파치 프로세스가 만들어져 작업을 처리한다는
것이다. 유닉스머신에서 각각의 요청이 있을때 마다 자식프로세스를 생성하여 사용한다는 점과
비교한다면 크게 달라진 것이다. 윈도우에서 만들어지는 프로세스중의 하나는 부모프로세스 이며
다른 하나는 웹서버의 요청을 핸들링 하기 위한 자식프로세스 이다. 자식프로세스 안에서 스레드에 의해
각 요청을 처리한다. 이리하여 프로세스 관리방법이 다음과 같이 달라졌다.

MaxRequestsPerChild - 유닉스하에서 사용하던 것과같이, 이것은 프로세스가 죽기전에 얼마나 많은 요청을 처리하는지를 설정한다. 그러나 윈도우에서의 프로세스는 모든 요청을 하나씩 처리하는 것이 아니라 한번에 처리하는 것이다. 그래서 이 값을 설정할때에는 높은값을 사용하도록 권장한다. 권장하는 디폴트 값은 MaxRequestsPerChild 0 이다. 어느정도의 일을 처리하고 죽는것이 아니라 계속 작동하는 것이다.

ThreadsPerChild - 이 값은 이번 윈도우 버전에서 새롭게 생긴것이다. 웹서버에게 얼마나 많은 스레드를 사용할 것인지를 설정하는 것이다. 이 값이 높다는 것은 한번에 핸들링 할수 있는 Connection 이 많다는 것이다. 만약 지금 운영하고 있는 사이트가 많은 접속률을 기록한다면 확실히 이 값을 높게 설정하여야만 할 것이다. 권장하는 디폴트 값은 ThreadsPerChild 50 이다.

위 값들은 실제 사이트를 운영해 나가면서 알맞게 조절해 사용하기를 바란다. 설정이 부적절한 경우에는
서버가 다운되버리는 현상이 발생할 수 있다. 위 값들은 단지 디폴트 값이며 NT 에서 제공하는 성능측정기
등을 이용하여 서버의 상태를 파악하여 알맞게 조절하기를 바란다. 또한,본격적으로 사이트를 운영한다면 Windows 95 or 98 에서 운영하기 보다는 Windows NT 에서 운영할것을 권한다. 거대 사이트 일경우에는 Windows 에서의 운영보다는 Unix 에서 운영하기를 바란다. 아직까지 Win32 for Apache 버전이 안정화되어 있지 않기 때문에 큰 사이트 일경우에는 약간 무리가 된다고 생각되어진다.

설정파일에서 바뀌어진것이 또 하나있다. 다름아닌 슬래쉬(/) 이다. 윈도우에서는 백슬래쉬(\)를 사용한다는 것은 컴퓨터를 한번이라도 다루어 본 사용자라면 잘 알것이다. 그러나 유닉스에서는 \ 대신 / 를 사용한다. 필자의 개인적인 생각으로는 \ 보다는 / 것이 훨씬 편하다. 왜 ! 굳이 MS 에서는 \ 를 고집하는지 모르겠다. :-) 아파치그룹에서는 유닉스 파일이름 대신 윈도우즈의 파일이름을 사용하자는 의견을 받아들였다. 그러나 아파치는 내부적으로 유닉스 스타일의 이름을 사용한다. 그러므로 여러분들은 백슬래쉬(\) 가 아닌 "/" 를 사용하여야만 한다. 드라이브 문자등은 사용할 수 있다.


마지막으로, 달라진점 하나만 더 다루겠다. 윈도우용 아파치는 모듈을 로드할때 서버의 재 컴파일 없이 사용이 가능하다는 점이다.(이 얼마나 편한기능인가 ?) 이러한 모듈등이 사용가능한것은 새로운 기능인 LoadModule 명령이 사용되어 지고 있기 때문이다. 만약 아파치가 디폴트로 컴파일이 되어 있는 상태에서 \Apache\modules 디렉토리 안의 모듈을 인스톨 하려고 한다면 어떻게 해야 할까 ? 예를 들면 status 모듈을 사용하려 한다면 단지 다음과 같이 적어 주기만 하면 된다. 또는 주석을 제거

LoadModule status_module modules/ApacheModuleStatus.dll

또한 , 아파치는 ISAPI Extensions(Internet Server Applications) 을 로드할수 있다. Microsoft IIS 와 다른 윈도우 서버에서 사용되는 것과 같은.... 더 많은 정보는 이곳에서 참고하기 바란다.

다음은 각 설정파일에 대해 설명하겠다. 단, 각 설정파일의 자세한 설명은 피하겠다. 자세한 설명은 메인페이지를 참고하기 바라며 아파치를 설치한후에 단지 httpd.conf 의 ServerName 만 바꾸어 주면 작동하는데는 별 무리가 없을것이다.

  • 4-1. httpd.conf

    도데체 웹 서버가 뭐냐 ? 빨리 보고 싶어 참을수 없다 싶으신 분들은 ServerName 만 일단 설정해 주십시오. 말 그대로 아파치 웹서버의 이름을 정해주는 것입니다. 도메인 네임을 가지고 있으면 도메인 네임을 넣어주면 되고, 갖고 계시지 않은 분들은 단지 루프백 어드레스인 127.0.0.1 을 넣어주시면 되겠습니다.

    #ServerName new.host.name
    ServerName 127.0.0.1

    NOTE: 서버네임을 설정하지 않을 경우 다음과 같은 메세지를 볼수 있다.

    C:\Program Files\Apache>apache
    httpd: cannot determine local host name.
    Use the ServerName directive to set it manually.

주의 : 구분하실때는 "\"(백슬래쉬) 이 아니라 "/"(슬래쉬) 입니다. 주의하세요.

질문 1) 저는 NT 4.0 를 사용하며 각 개인 유저들의 디렉토리를 "d:\users" 라는 곳에
모두 설정해 놓았습니다. 어떻게 하면 유저들에게 개인 홈페이지를 운영할수 있도록
할수 있을까요 ?

답변: 아파치웹서버를 이용하십시오. 다음 srm.conf 를 다음과 같이 편집해 주십시오.

UserDir "d:/users/*/public_html"

이렇게 하시면 d:\users 안에 속해 있는 각 유저들의 디렉토리 밑에 public_html 디렉토리를 만들어 개인 홈페이지를 개설할 수 있습니다.

5. 시동

아파치를 실행하기 위한 방법으로 두가지가 있다 :
하나는 NT 에서 제공하는 "서비스" 를 이용하는 것이다 (단, 이것은 NT 에서만 사용가능하다) 컴퓨터 부팅후에도 아파치가 자동으로 작동하기를 원한다면 이 옵션은 아마도 최고의 선택 방법일 것이다. 이 기능은 로그오프 한 후에도 계속 동작할 것이다. 윈도우 95 사용자들은 Console Window 를 이용하여 사용가능하다.

"서비스" 로서 아파치를 작동시키려 한다면, 먼저 그 서비스를 인스톨 하여야 한다. 시작메뉴 --> 프로그램 --> Apache Web Server 의 "install Apache as Service(NT only)" 옵션을 실행시키자!! 아파치를 실행시키기 위해서는 제어판 안에 있는 "서비스" 를 먼저 오픈한 다음 아파치를 선택하고 그때 "Start" 를 클릭하면 된다. 이때 아파치는 백그라운드로서 작동할 것이며, 스톱을 원한다면 위와 같은 방법으로 다시 "Stop" 을 클릭하면 된다.

다른 방법으로 서비스를 작동시킬수도 있는데 , 도스창에서 다음과 같은 방법으로 시작 및 중지시킬수도 있다.

NET START APACHE
NET STOP APACHE

또는, 시작메뉴에서 "Apache Server" 를 선택하여 콘솔윈도우에서 아파치를 실행시켜라 !!
이것은 도스창을 하나 오픈 한다음 아파치를 작동시킨다. 이 윈도우는 아파치를 중지시킬때 까지 계속 작동할 것이다. 아파치를 중지시키기 원한다면 6 번 메뉴 "종료" 를 참고하기 바란다.

아파치를 시작한후에(도스창 또는 "서비스" 를 이용) 80 번포트로 접근할수 있을 것이다.
(포트는 설정파일에서 Port,Listen or BindAddress 를 이용하여 바꿀수 있다)
브라우저를 하나 실행시키고 아래와 같이 URL 을 입력하면 웹서버의 default page 에 엑세스 할수있을 것이다.

http://localhost/ 또는 http://127.0.0.1

엑세스에 성공하면 웹 서버는 환영의 메세지로 대답할 것이며 , 아파치 메뉴얼의 링크를 볼수 있다(자세한 것은 아파치에서 제공하는 메뉴얼 또는 http://www.apache.kr.net 을 방문) 만약 아무것도 일어나지 않거나 에러메세지를 본다면 먼저 logs 디렉토리의 error_log 파일을 보기 바란다. 문제의 원인을 이 로그파일로 인해 쉽게 찾을수 있을 것이다.
conf 디렉토리안의 설정파일등을 자기 서버에 맞게 적절하게 설정하여 사용하기를 바란다.

시작메뉴의 아이콘과 NT 서비스 관리자는 아파치를 좀더 쉽게 관리할수 있도록 간단한 인터페이스를 제공해 주고 있다. 그러나 이것들은 단지 커맨드라인에서 쉽게 사용할수 있도록 해줄뿐이다. 자 그럼 ! 일단 아파치가 설정파일들을 어떻게 찾는지 알아보자. 모든 것이 자동으로 해결해 줄거라고 믿지 말자 ! 만약 이렇게 생각하고 있다면 큰 오산이다. 아파치는 아래와 같은 방법중의 하나로 실행할 수 있다.

  • -C 스위치를 통해 ServerRoot 를 설정할수 있다.
  • 도스창에서 -f 스위치를 사용
  • 도스창에서 -d 스위치를 사용
  • 바이너리 파일을 인스톨 하였다면 윈도우의 레지스터리 값을 이용
  • 컴파일시에 서버루트를 설정

아파치컴파일시에 서버루트는 "/apache" 로 설정된다. 이 값은 아파치 실행시 -V 옵션을 통해 HTTPD_ROOT 의 설정된 값을 확인할수 있다. 아파치를 시작할때 아무런 옵션없이 실행될때에는 자동으로 HTTPD_ROOT 가 작업디렉토리가 된다. 윈도우 하에서 시작메뉴 또는 서비스관리자에서 아파치를 아무 인수없이 불러낼 경우에는 윈도우의 레지스터리 값을 이용해 시작된다. 레지스터리 키값은 바이너리가 인스톨 되는 과정에 설치될 것이며 regedit 또는 regedit 32 를 이용하여 다음과 같은 키 값을 볼수 있을 것이다.

HKEY_LOCAL_MACHINE\Software\Apache Group\Apache\1.3.1\ServerRoot

만약 바이너리 버전을 인스톨 하지 않으면 아파치는 없어진 레지스터리 값에 대해 불만을 토로할 것이다. :-) 설정파일을 다른곳에서 찾을수만 있다면 이 경고는 무시해도 좋으며, 에러메세지는 다음과 같다 :

C:\Program Files\Apache>apache
[Sun Jan 03 22:19:24 1999] [warn] Registry does not contain value SOFTWARE\Apach
e Group\Apache\1.3.3\ServerRoot
fopen: No such file or directory
httpd: could not open document config file /apache/conf/httpd.conf

"ServerRoot" 의 키 값에는 conf 디렉토리도 포함되어 있다. 아파치가 시작될때 이 디렉토리로부터 httpd.conf 파일을 읽어 들인다. 만약 httpd.conf 에 포함되어 있는 ServerRoot 의 값이 위의 레지스터리 값과 다른것을 가지고 있다면 아파치는 기존의 레지스터리 값을 잊어버리고 설정파일에 설정된 디렉토리를 사용할 것이다. 여러분들이 아파치 디렉토리 또는 설정 파일을 새로운 곳으로 복사하였다 하더라도 httpd.conf 에서 새로운 ServerRoot 의 위치만 지정해 주면 아파치는 다시 쉽게 가동될 것이다.

아파치를 작동시키기 위하여 커맨드라인에서 다음과 같은 명령어를 사용할수 있다:

apache -s

아파치는 실행될 것이며, Control-C 가 눌러질때 까지 멈추지 않고 계속 작동할 것이다.
(윈도우 95 에서는 -s 옵션이 필요하지 않다.)
Windows NT 서비스 로서 작동하는 것을 인스톨 하려면 :

apache -i

서비스에서 제거하려면 :

apache -u

6. 종료

윈도우 95 에서 콘솔프로그램에 의해 아파치가 작동하고 있다면 또다른 도스창을 오픈한 다음 다음과 같은 명령어로 작동중인 아파치에게 멈출것을 명령할 수 있다.

apache -k shutdown

주의: 이 옵션은 아파치 1.3.3 그리고 이 이상의 버전에서만 가능하다. 초창기 버전에서 사용하려면 콘솔윈도우에서 Control-C 를 사용하여 shut down 시킬수 있다. 아파치 콘솔 윈도우에서 Control-C 를 눌러 작동을 중지시키기 보다는 이 옵션을 사용하기 바란다. 왜냐하면 이 옵션은 아파치에게 현재의 작업등을 깨끗하게 처리하고 멈추라고 지시하기 때문이다.) 이 옵션을 사용하지 않고 강제종료시는 흔히 다음과 같은 메세지를 볼 수 있을 것이다.

[Sat Jan 02 16:33:40 1999] [warn] pid file c:/program files/apache/logs/httpd.pi
d overwritten -- Unclean shutdown of previous apache run?
Apache/1.3.3 (Win32)

또한 아파치에게 재시작을 지시할 수 있다. 이것은 아파치의 중지없이도 설정파일등을 다시 읽을수 있다. 그 만큼 서버다운시간을 줄일 수 있다는 이야기 이기도 하며, 아파치를 재시작 하기 위해서는 다음과 같이
실행하면 된다.

apache -k restart

주의 : 이 옵션은 아파치 1.3.3 그리고 이 이상의 버전에서만 가능하다. 이전 버전에서는 콘솔윈도우에서 Control-C 를 사용해 서버를 shut down 시켜야 한다.

이 명령어는 유닉스에서 사용하던 kill -TERM pid 그리고 kill -USR1 pid 와 동등한 기능을 윈도우에서도 제공한다.


Posted by wrnly
프로그램/web server2011. 2. 19. 11:21

Subversion 서버 구축하기

 1. 설치 목표

Http 프로토콜로 SVN 서비스 지원하도록 서버측 환경을 만드는 것을 목적으로 한다. svn 프로토콜이나 https로 하는 방법은 생략한다. 이 목표를 달성하기 위해 다음과 같은 프로그램을 다운로드 받아 설치해야 한다.

- Apache 웹서버 2.2.x

- Subversion 1.6.x

- TortoiseSVN 1.6.x

2. Apache 웹서버 설치 하기

http://httpd.apache.org/download.cgi 에서 Openssl을 지원하는 Win32 Binary 설치프로그램을 다운로드 받아 설치한다. 현 최신 버전인 apache_2.2.11-win32-x86-openssl-0.9.8i.msi를 받아 설치함

3. Subversion 서버 설치

http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100 에서 Apache 2.2 모듈을 포함하는 최신 SVN 바이너리 프로그램을 받는다. 현 최신 버전인 Setup-Subversion-1.6.3.msi를 받아 설치함

4. TortoiseSVN 설치 하기

이 프로그램은 클라이언트에서 주로 사용한다. 콘솔창에서 svnadmin create와 같은 명령어를 이용해 저장소 만드는 불편함을 없애기 위해 설치한다.

http://tortoisesvn.net/downloads 에 가서 다운로드 받아 설치한다. 현 최신 버전인 TortoiseSVN-1.6.3.16613-win32-svn-1.6.3.msi를 설치하면 된다.

5. SVN 저장소(Repository)를 생성한다.

저장소를 만들기 위해svnadmin create 명령어를 콘솔창에서 하는 방법도 있지만 방금 설치한 TortoiseSVN을 이용하면 쉽게 만들 수 있다. 먼저 아래 그림처럼 임의의 위치에 저장소 폴더를 만든다. 그리고 오른쪽 마우스 버튼을 눌러 컨텍스트 메뉴에서 TortoiseSVN을 선택한 뒤 Create repository here를 선택하면 된다. 그럼 The repository was successfully created 메시지가 뜨면서 저장소가 만들어진다. 테스트를 위해 저장소를 C:\svn 에 만들었다.

만들어진 저장소에 들어가보면 아래와 같은 내용이 만들어진 것을 확인할 수 있겠다.

conf 폴더 안에 있는 authz, passwd, svnserve.conf를 설정하여 이 저장소에 접근할 수 있는 권한 및 운영제반 사항을 설정할 수 있다. http 프로토콜로 서비스를 할 것이므로 authz 설정만 하면 된다. 즉, passwd와 svnserve.conf는 건드릴 필요가 없다. 이들은 svn프로토콜을 이용하면 반드시 설정해야한다.  설정 방법은 다음에 설명한다.

6. Apache 서버에 SVN 모듈 등록

Subversion의 설치 폴더(C:/Program Files/Subversion)에 bin폴더에 있는 mod_dav_svn.so와 mod_authz_svn.so 파일을 Apache의 modules 폴더에 복사한다.

그 다음 Apache 설치 폴더에 conf 폴더에 있는 http.conf를 아래와 같이 편집한다.

# 아파치 모듈 설정 부분에서 다음 부분의 주석을 푼다.
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so

# 다음과 같은 SVN 모듈을 추가한다.
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

7. Apache 가상 호스트 설정

가상호스트는 말그대로 가상적인 호스트를 의미한다. 앞으로 만들 SVN 저장소에 접근할 수 있도록 가상으로 정한 주소를 이용해 Apache에 설정하는 것을 의미한다.

여기서 Apache 2.2 버전을 설치했으므로 http.conf에 아래 부분 처럼 가상 호스트 관련 설정파일을 포함하도록 되어 있다. Include 앞에 #을 지워준다.

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

Apache 설치폴더에서 conf/extra/httpd-vhosts.conf 를 열어서 다음과 같이 추가한다.

############################################
# Sample 테스트용 SVN 가상호스트
############################################
<VirtualHost *:80>
    <Location /svn/test>
        DAV svn
        SVNPath "C:\svn"
        #SVNParentPath "C:\svn"
        #SVNListParentPath On
        AuthType Basic
        AuthName "SVN Test Repository"
        AuthUserFile "c:\svn\htpasswd"
        AuthzSVNAccessFile "c:\svn\conf\authz" 
        Require valid-user
    </Location>
</VirtualHost>

위 설정은 http://주소/svn/test 로 접근하게 되면 C:\svn 을 SVN 저장소 위치로 찾게 해준다는 의미가 내포되어 있다.

AuthUserFile은 사용자 목록 위치이며 AuthzSVNAccessFile은 접근권한 파일을 의미한다. 주석 처리된 SVNParentPath는 각 프로젝트의 저장소 디렉토리가 아닌 그 바로 위의 디렉토리를 뜻한다. http://주소/svn/test로 접속하여 C:\svn 뿐 아니라 http://주소/svn/test/other 로 하면  C:\svn\other 로도 접근이 가능해지는 것이다.

Require valid-user는 인증된 사용자만 사용할 수 있다. 만약 체크아웃(check-out)은 아무나(Anonymous)가 할 수 있게 하고 커밋(commit)은 지정된 사용자만 할 수 있게 하려면 Require valid-user 대신 아래처럼 사용할 수 있다.

############################################
# Sample 테스트용 SVN 가상호스트
############################################
<VirtualHost *:80>
    <Location /svn/test>
        DAV svn
        SVNPath "C:\svn"
        #SVNParentPath "C:\svn"
        #SVNListParentPath On
        AuthType Basic
        AuthName "SVN Test Repository"
        AuthUserFile "c:\svn\htpasswd"
        AuthzSVNAccessFile "c:\svn\conf\authz"  
        <LimitExcept GET PROPFIND OPTIONS REPORT>
            Require valid-user
        </LimitExcept>
    </Location>
</VirtualHost>

8. Apache 사용자 인증 파일 생성

위에서 AuthUserFile의 경로를 설정할 것을 보았을 것이다. 이제 그 파일을 만들자.

http 프로토콜을 사용하여 SVN에 접근하므로 Apache의 htpasswd를 이용해 사용자 인증을 한다.

htpasswd 파일을 생성은 다음과 같이 한다.

{아파치 설치 폴더}\bin\htpasswd -c htpasswd 사용자계정

htpasswd 파일에 사용자 추가 명령

{아파치 설치 폴더}\bin\htpasswd htpasswd 사용자계정

위와 같은 방법으로 사용자 계정을 추가해보자.

C:\svn\conf>C:\Apache\Apache2.2\bin\htpasswd -c htpasswd jidolstar
Automatically using MD5 format.
New password: ********
Re-type new password: ********
Adding password for user user1

만들어진 c:\svn\htpasswd 파일을 보면 아래와 같이 추가 되어 있는 것을 확인할 수 있을 것이다.

jidolstar:$apr1$IswHvHiJ$rBcOZc8bs59IUJIC/hWgO.

중요한 것은 -c는 한번만 사용한다. 안그러면 이전 내용이 지워져 버린다.

9. Subversion 접근 권한 파일 설정

c:\svn\conf 폴더에 보면 authz, passwd, svnserve.conf 파일이 있다. svn 프로토콜로 접근하지 않을 것이므로 authz만 수정하면 된다.

다음은 authz 파일 접근 권한 설정의 예이다.

[groups]
group1 = user1,user2
group2 = user3,user4,user5

[/]
* = r

[/project1]
@group1 = rw
@group2 = r

[/project2]
@group1 = rw
@group2 = r

무엇을 의미하는가? 2개의 그룹이 있다. 그룹 group1에는 사용자 1,2가 있고 그룹  group2에는 사용자 3,4,5가 있다. 이들은 http://주소/svn/test로 접근했을때 모두 read할 수 있으나 write권한은 없다. http://주소/svn/test/project1 에는 group1은 read/write를 다할 수 있으나 group2는 read만 할 수 있다. project2는 그 반대이다. 이런 식으로 svn에 접근 권한을 설정할 수 있는 것이다. 앞서 설명했지만 이 파일은 앞서 수정했던 가상 호스트 설정에서 Apache가 실행될 때 로드되어 진다.

본인은 앞서 jidolstar 아파치 계정을 하나 만들었으므로 다음과 같이 authz를 설정했다.

[groups]
group1 = jidolstar

[/]
* = rw

10. 웹브라우저에서 SVN 서버에 http로 접근하기

아래와 같은 윈도우 맨 우측아래 트레이 아이콘을 두번 클릭해 창이 뜨면 아파치를 구동하자. 미리 구동되어 있는 경우에는 새로운 설정을 로드해야하므로 stop했다가 다시 start한다. 위 설정을 잘 했다면 에러없이 구동이 될 것이다.

먼저 아파치가 잘 구동되는지 확인한다. 아래와 같이 창이 뜨면 정상이다. (참고로 이 페이지는 {아파치 설치경로}\htdocs에 있는 index.html 파일이다.)

이제 http://localhost/svn/test 로 접속해보자. 아래와 같은 인증창이 나오면 등록했던 사용자계정정보를 넣자.

인증이 완료되면 아래와 같은 화면이 나왔으면 성공이다.

이것으로 SVN 서버 구축을 모두 완료했더 테스트 까지 마쳤다.

여기서는 c:\svn에 저장소를 만들었지만 사람마다 다른 곳에 저장소를 만들고 싶을 것이다. 원하는 곳에 저장소를 만들어 테스트를 꼭 해보길 바란다. 가상호스트는 중복으로 만들 수 있으니 여러개의 저장소를 만드는 것도 가능하다.

Subversion 서버에 HTTP로 접속해 사용해 보기

SVN 서버는 모두 구축이 되었다. 이제 개인 소스 관리를 위한 테스트를 해보자. 만약 다른 컴퓨터에서 테스트 해보고 싶다면 그 컴퓨터에 TortoiseSVN 을 설치하길 바란다.

1. 체크아웃(check-out)

먼저 SVN 서버에 c:\svn에 있는 자료를 첫번째로 가져오는 일을 해야할 것이다. 이때 하는 일이 check-out이다. 바탕화면에 TestSVN 폴더를 만들어보자. 그런다음 아래 그림처럼 SVN Checkout를 실시한다.

그럼 아래처럼 Checkout 창이 뜬다. 우리는 http://localhost/svn/test 로 접속해서 이전에 만들어진 저장소 C:\svn에 있는 내용을 읽어올 수 있다고 했다. 아래처럼 URL of repository에 이 URL을 적고 OK버튼을 누른다.

브라우져에서 접속할때와 마찬가지로 인정절차가 필요하다. username과 password를 넣자. 다음부터 이 절차를 생략하고 싶다면 Save authentication을 check한다.

아래와 같이 Completed 가 나오면 완료가 된것이다. 지금은 아무 내용이 없다. ^^;

바탕화면에 만든 TestSVN 폴더에 보면 .svn 이 생성된다. .svn은 TestSVN이 접속한 저장소에 대한 정보를 가지고 있다. 앞에 점(.)이 있기 때문에 폴더옵션에서 숨김 파일 및 폴더 표시를 해주어야 보인다. 그렇지 않으면 TestSVN은 빈폴더처럼 보일것이다.

2. 커밋(commit)

체크아웃 한 소스를 수정, 파일 추가, 삭제 등을 한 뒤 저장소에 저장하여 갱신 하는 것이다. 커밋을 하면 전체 리비전이 1 증가하게 된다.

해보자. 앞에서 체크아웃한 TestSVN 폴더 내로 가서 tags, trunk, branches 폴더를 만든다. 또 각각의 폴더안에 tags.txt, trunk.txt, branches.txt를 만들어 본다. ? 표가 표시된 것은 이 파일이 어떤 상태인지 모른다는 것을 의미한다.

모두 선택한 뒤 아래처럼 TortoiseSVN > Add를 선택해서 커밋할 목록으로 등록한다.

이제 ?표에서 벗어나 + 표시로 바뀌었다. SVN 서버로 커밋할 준비가 된 것이다.

모두 선택한 뒤 아래 화면처럼 SVN Commit을 실시한다.

아래 그림의 창이 뜨면 SVN으로 전송할 목록이 선택되어 있고 Message를 남길 수 있게 된다. 이런식으로 만들어진 자료를 SVN로 전송할 수 있다. 지금은 추가된 내역만 올라가지만 만약 폴더 이름이 바뀌거나 위치를 옮기거나 삭제 되었거나 했을때는 added가 아니라 deleted, moved 이런 표시가 붙을 것이다.

아래 화면처럼 추가했던 + 표시는 없어지고 체크표시가 되었다. 정상적으로 SVN 서버에 올라간 것이다.

trunk를 선택하고 오른쪽 마우스 키를 눌러 Tortoise > show log를 보자. 아래처럼 Revision 번호가 1로 되어 있는 것을 확인할 수 있으며 그에 대한 Message와 함께 Commit된 것들도 확인할 수 있다.

TestSVN/trunk/trunk.txt 파일을 열어 내용을 입력하고 저장해보자. 아래처럼 !(느낌표) 표시가 될 것이다.

이것을 커밋해보자. 기존에 있는 것을 수정했으므로 상태는 modified가 되어 있다. 커밋하면 이제 리비전(revision)은 1에서 2로 바뀌게 된다.

브라우저에서도 확인해보자. http://localhost/svn/test 로 접속해서 아래와 같은 화면을 확인하자. add, modify 두번 처리해서 커밋했으므로 Revision이 2이다.

3. 업데이트(Update)

체크아웃을 해서 소스를 가져 왔더라도 다른 사람이 커밋(추가, 삭제, 이동, 변경등)을 하였다면 소스가 달라졌을 것이다. 이럴 경우 업데이트를 하여 저장소에 있는 최신 버전의 소스를 가져온다. 물론 바뀐 부분만 가져온다.

다른 사람이 변경한 내용이 있더라도 내가 변경한 내용이 따로 있다면 그 파일이나 폴더는 무시한다. 그러므로 항상 작업을 할 때는 먼저 업데이트를 하고 난다음 수정, 추가, 삭제, 이동의 작업을 완료후에 커밋해야 다른 사람 변경내용과 충돌이 일어나지 않는다. SVN은 겹쳐서 작업해서 서로 소스가 달라지는 경우 충돌보고를 해주기 때문에 안심하고 작업할 수 있다.

업데이트 방법은 매우 단순하다. 아래 그림처럼 SVN Update만 해주면 된다.


정리하며

윈도우 환경에서 Subversion 서버를 구축하는 방법과 사용법을 간단히 논했다. 사실 아주 일부분만 설명되어 있는 것이고 실무에서는 더욱 다양하게 쓰이게 된다. 개발자의 경우 TortoiseSVN을 이용한다기 보다 Eclipse나 Flash Builder 등에 SVN 플러그인을 설치하여 개발 코드 관리를 하는 것처럼 사용한다.

외부 컴퓨터에서 접속이 가능하게 하려면 반드시 80번 포트의 방화벽을 해제해주어야 한다.

쉬운 내용이지만 한번 정도는 정리할 필요가 있다고 생각했다. 막상 작성해보니 내용이 너무 길다. ^^;


Posted by wrnly