It's Myself

각종 서버상에서 남는 로그는 일반적으로 500M 정도는 훌쩍 넘는다.
그래서 일전에도 대용량 데이터를 처리하기 위한 Logger Viewer를 만든 적이 있었는데,
기능에 비해 제약사항이 큰 바람에 결국 중도 하차한 프로그램이다.
(나중에 틈 되는 대로 손볼 예정이다. )

이번에 받은 Text 파일도 의외로 커서, 일반 Text Editor로 제대로 열지를 못한다.
(강세 Swap 처리하는 Ultra Editor도 있긴 하지만, 일단 여는데 너무 많은 시간을 소요한다.)

단순 Text 조회 ( 절대 수정하지 않는다는 조건 )일 경우에 가장 쓸만한 Tool이 있어 소개한다.

그 프로그램 이름은 단순하게도 Large Text File Viewer 줄여서 LTF Viewer라고 한다.

사이트 URL은 다음과 같다.

http://www.swiftgear.com/ltfviewer/features.html

현재 (2014-08-23 기준)으로 5.2 버전까지 나왔다.
License 문제는 애초에 언급되어 있지않고, 별도 설치도 필요없고, 그 크기도 500K 내외에 불과하다.

설치 및 사용방법은 다음과 같다.

1. 상단의 Download를 통해서 프로그램 파일을 다운 받는다.
2. LTFViewer.zip 파일을 다운 받을 수 있는데, 그 압축 파일을 적당한 위치에 풀도록 한다.
3. 압축을 다 풀었으면, 압축을 푼 곳에서 LTFViewer5u.exe 를 실행한다.
4. (보안 경고가 나오면 무시하고 연다.)
5. 끔찍한 배경 화면은 무시하고, 좌측 상단에 위치한 열기버튼()을 클릭한다.
6. 원하는 파일을 연다.

사용해 본 결과 상당히 매끄러운 스크롤을 지원하며, 파일 Open 역시 매우 빠르게 열린다.

배경화면이나, 표시하는 Font 등을 변경하고 싶으면, 설정 버튼()을 누르면 이 프로그램의
각종 설정이 가능하다.

로그파일 뷰어로는 이거 만큼 훌륭한 것을 찾기는 어려울듯…

서두 ( 넋두리 )

ESXi 서버를 운영할 때, 사실 ESXi 클라이언트 프로그램만 있다면, 큰 문제 없이 사용할 수 있다. Guest PC의 제어는 물론 Console창까지.. 다양한 기능을 제공하는 종합 관리 도구라고 볼 수 있다.

하지만, 이 ESXi 서버가 방화벽안에 들어가 있어, 외부에서 접속을 하려면, 생각보다 난제점이 많다. 다양한 기능을 제공하는 만큼 다양한 네트워크 리소스가 필요한데, 아래와 같은 다양한 네트워크 포트를 열어야 한다.

사용할 네트워크의 종류를 나눠서 필수적으로 열어야 하는 포트만 정리하여 구성할 수 있지만, 그것도 1대의 ESXi 서버에서만 해당되고, 여러 대인 경우에는 불가능 할 수 밖에 없다. 최종적으로는 VMWare 측에 vSphere 를 한꺼번에 관리하는 서버 라이센스를 구매해서 관리하는 방법 밖에는 없다.

하지만, 가난한 작은 회사에서 2~3대의 ESXi 서버를 관리하기 위한 솔루션으로 구매하기는 그리 쉽지 않다. ( 상신 올려도 승인 받기까지의 과정은 정말이지… )

차선으로 생각한 방법은 아래와 같다.

인터넷 공유기에 ESXi 서버 두대와 별도 PC를 연결한다. 그래서 별도 PC에 ESXi 클라이언트를 설치하고, 해당 PC의 원격 연결 (MS-RDP : MS 원격데스크톱)을 통해서 두대의 EXSi 서버를 관리하게 끔 했다. 즉 원격에서는 3389 포트를 사용하는 원격 데스크톱을 이용해 접속하여, 각각 존재하는 ESXi 서버를 관리하고, 그 안에서 Console 을 열어 관리한다.

만일 GUEST PC가 Windows라면, 마찬가지로, 각 Guest PC별로 MS-RDP 포트를 열고, 공유기에서도 그에 맞게 포트를 열어 관리했다. (물론 3389대신 다른 포트로 Open )

이처럼 했더니, 원격에서도 나름 원활하게 각 가상 PC들을 관리하는데 그나마 수월하게 할 수 있었다.

문제 발생

사실 운영에는 큰 문제가 없었는데, 갑자기 Linux를 Guest PC로 추가하려다 보니, 이게 또 다른 난제를 불러왔다. ESXi 관리 PC를 원격에서 연결한 상태에서 Console을 띄우니, 상당히 불편함을 가져왔다. 단순히 운영체제를 설치하는 정도면 그냥 저냥 참고 진행하면 되는데, 실제 운영체제 내부를 사용하려 할 때는 무척 불편함을 느낄 수 있다. 화면이 껌뻑임도 문제였고, 마우스나 키보드 잠김은 정말이지 짜증이 발생한다.
Windows 기반의 Guest PC는 그냥 MS-RDP 포트를 열어 직접 연결을 하면 되지만, Linux의 경우에는 그렇게 되기 힘들다. 물론 MS-RDP를 흉내넨 xRDP라는 것도 있지만, 매번 Guest OS가 Linux일 때마다 설치하기에는 한계가 있기 때문에, 이 작업은 아니다 싶다.

VNC

Open-Source로 원격에서 GUI 화면을 그대로 접속할 수 있는 Console 개념의 프로토콜이다. Open되어 있는 프로토콜이라, 이 유형을 가지고 제작된 제품군들은 생각보다 많다. 당연히 Linux 계통의 원격 접속은 대부분 이 VNC를 통해 접속하여 관리하게 한다.

다양한 제품군들이 있지만, 그 중 TigerVNC를 사용한다. 다른 여러 제품들이 있지만, 상용으로 전환된 제품도 있고, 성능상 이슈가 발생되는 제품들도 있다. 그 중 이 tigervnc는 현재도 지속적으로 업데이트되고 있으며, Linux 진영에서도 밀어주고 있는 제품이라고 한다.

http://tigervnc.org/

여기서는 VNC 서버는 ESXi 가 되고, 클라이언트만 있으면 된다.

준비 작업

이제 VNC를 통해 원격에서 해당 콘솔 화면을 열 수 있도록 한다. 이를 위해서는 몇 가지 준비 작업 및 권한들이 필요하다.

1. 방화벽 관리
   인터넷 공유기나, 기타 방화벽 관련된 서비스 안에 ESXi 서버가 있는 상태에서 외부에서 접근할 때는 반드시 방화벽 관련 권한이 있어야 한다. 특정 포트를 열어주어야 하기 때문에, 그에 상응 하는 기술 능력이나, 접근 권한이 필요하다.
   
2. SSH 접속 프로그램
   ESXi 서버 내부에 들어가 접근해야 하는데, 전용 클라이언트 도구가 아닌, Linux 로 된 EXSI 서버 자체를 접속해야 된다. 이 때문에, Telnet 기반의  SSH 접속 프로그램이 필요하다. 다양한 SSH 접속 프로그램이 있지만, 그중 무료로 제공되는 작은 제품인 Putty ( http://www.chiark.greenend.org.uk/~sgtatham/putty/ ) 을 사용하면 된다.
   
3. ESXi 클라이언트
   기초적인 설정 작업은 EXSi 클라이언트를 통해서 진행하게 된다.

작업 ( VNC 활성화  )

기본적으로 설치는 되어 있지만, VNC에 대한 활성화가 안되어 있다. 이를 위한 몇 가지 작업을 수행해야 한다.
이 작업은 VNC로 연결할 VM 마다 해줘야 한다.

1. EXSi 클라이언트를 실행한다.
   
   
2. 설정을 할 VM을 선택 한 뒤, Edit Settings를 선택해서 Virtual Machine Properties 화면으로 들어간다.
   ( 단, 이미 실행 중인 VM인 경우 Shutdown 하고 난 뒤에 해야 한다.! )
   
   
3. Virtual Machine Properties 화면에서 2번째 탭의 “Options” 안에 있는 General을 선택 한 뒤, “Configuration Paramters .. “ 버튼을 클릭한다.
   
   
4. Configuration Paramters 창에서 하단에 위치한 “Add Row” 버튼을 눌러 새로운 줄을 생성한 뒤에, 다음 내용을 넣도록 한다.
   
   
   1. Name : RemoteDisplay.vnc.enabled
      Value : TRUE
   2. Name : RemoteDisplay.vnc.port
      Value : {원하는 연결 포트 번호 : 여기서는 15900 }
   3. Name : RemoteDisplay.vnc.password
      Value : {원하는 접속 암호 : 여기서는 P@ssw0rd

만일 VNC를 활성화할 VM이 더 있다면, 해당 VM을 선택해서 “2”번 단계를 반복하면 된다.

작업 ( SSH 연결 기능 활성화)

ESXi 서버를 SSH로 연결이 불가능한 경우를 위해서 작업하는 내용으로, 기존에 SSH로 연결할 수 있도록 설정되어 있다면 다음 작업으로 넘어간다.

1. ESXi 클라이언트를 실행한다.
2. Inventory 트리에서 최상위 노드를 선택한다.
   그리고 오른쪽 탭에서 Configuration을 선택한다.
   
   
3. Configuration 탭 내에서 “Security Profile”을 선택한 뒤에 Services 영역에 위치한 “Properties”를 선택한다.
   
   
4. Service Properties 창에서 SSH를 선택 한 뒤, Options를 선택한다.
   
   
5. SSH Options 창에서 “Start” 버튼을 눌러주고 “OK” 하면 된다. (만일, 이후에도 계속 SSH 서비스를 이용할 예정이면, “Start and stop with host”를 선택하면 된다. )
   
   

작업 ( 방화벽 Open )

기본적으로 VPN을 위한 방화벽이 열려있지 않다. 그래서 이를 위해 별도로 방화벽을 열기 위한 구성을 해주어야 한다.

1. SSH를 통해 ESXi 서버를 연결한다. (Putty 같은 SSH 연결 프로그램 사용 )
   
   
2. root 계정으로 로그인한다
   
   
3. firewall 디렉토리로 이동한다.

   cd /etc/vmware/firewall

4. 다음 명령을 넣어, vnc.xml 파일을 만들어 연다.

   cat > vnc.xml

5. 이제 다음 XML 파일 내용을 붙여 넣은 뒤, Ctrl + D를 눌러 저장한다.
   ( 안의 내용 중, port의 Begin과 End에 들어간 부분이 Open될 Port 번호의 시작과 끝 이므로, 적절하게 변경한다. )
   <ConfigRoot> <service id='0033'> <id>vnc</id> <rule id='0000'> <direction>inbound</direction> <protocol>tcp</protocol> <porttype>dst</porttype> <port> <begin>15900</begin> <end>15910</end> </port> </rule> <enabled>true</enabled> <required>false</required> </service> </ConfigRoot>
   
6. 다음 명령을 넣어, 저장한 XML 파일을 EXSi 서버에 등록한다.
   

   esxcli network firewall refresh

7. 이제 EXSi 클라이언트로 돌아와, Host 최상위 노드 –> Configuration 탭 –> Security  Profile을 열어서, 하단에 위치한 Firewall을 보면, vnc라는 항목이 나타난다. ( 안나타났다면, XML 파일 오류일 가능성이 크므로, 3번 단계 부터 하나씩 다시 확인해봐야 한다.
   

작업 ( 방화벽 Open )

이 작업은 공유기 및 방화벽 S/W의 구성에 따라 다르므로, 별다른 언급은 하지 않는다. 다만, 해당 공유기에 맞게 위에서 설정된 Port 번호에 해당되도록 Open 해주어야 한다.

현재 필자의 경우 15900 ~ 15910 까지 Open되어 있어, 그에 맞게 방화벽을 수정했다.

연결 해보기

VNC 연결은 오로지 화면 콘솔만 제공되기 때문에, 실질적으로 연결을 하려면, VM 자체를 시작해야 한다.

1. VNC로 연결할 VM을 실행한다.
   
2. TightVNC를 실행한다.
   
3. VNC 서버에 방화벽 밖에서 접근이 가능한 IP 주소를 입력하고, “:”를 사용하여 포트번호까지 입력한다.
   예를 들어 방화벽 바깥의 실제 IP가 121.223.10.5 이고, VNC Port를 15900으로 설정했으면,
   121.223.10.5:15900 이라고 주소 창에 입력하면 된다.
   
   
4. Password 입력 창에 앞서 설정한 암호 값을 넣는다.
   

최종적으로 연결이 성공되면 아래 화면같이 현재 VM이 떠 있는 화면이 그대로 노출된다.

결론

처음 출발은 MS-RDP가 안되는 리눅스 콘솔들을 접속하는 방법 때문에 찾아서 적용해봤는데, 해보고 보니, 각종 Geust OS를 설치할 때도 유용하다는 생각이다. VNC 프로토콜 자체가 보안에 취약한 문제점이 있지만, 간단 간단하게 접근해서 사용한다면 나쁜 선택만은 아닌 것 같다. 만일 보안이 우려된다면, 방화벽 내에 VNC을 구성해서 연결하는 것도 방법일 것 같다.

VM 설정이나 변경 작업에는 유용하지 않다. 결국 방화벽 내에 EXSi 클라이언트가 동작하는 관리 PC는 어쩔 수 없이 존재해야 한다. 하지만, 외부에서 콘솔로 해당 PC의 화면을 그대로 보려고 할 때는 정말 유용한 것 같다.

글 내용 중, 일부 노출되기 꺼리는 부분을 모자이크 처리를 한 점에 대해 양해의 말씀을 드린다. 다만, 모자이크 내용으로 인해 설정이 어렵거나 힘든 부분은 없으므로, 모자이크 부분은 그냥 무시하시면 된다.

Windows Vista 부터 보안 정책이 대거 변경 되었다.
먼저 로그인 자체 구조 부터 아예 변경되어 과거 Windows XP에서는 로그인하면,
시작 부터 아예 Administrator였다. 이것을 완전히 뜯어 고쳐서 현재는 진짜 Administrator 그룹에 포함되어도, Administrator가 아니게 되었다.

지금은 중요 자원을 손대려면, UAC(User Access Control)이라는 구조를 통해 일시적으로 Administrator의 권한을 할당 받아 처리되게 된다. 주요 자원이란, 레지스트리 중 Local Machine 이라고 하는 부분( 모든 사용자, 컴퓨터 모든 자원에 대한 설정 )이라든가, Windows 폴더, Program Files 폴더 등, 모든 사용자들에게 적용 받거나, 동작에 있어 가장 중추적인 역할을 하는 자원들을 말한다.

UAC를 거치게 되면 아래의 화면 처럼, 팝업 주위가 모두 꺼멓게 반전되면서, 계속 실행할지를 묻게 된다.

사용자 허락도 없이 마구잡이로 실행되어 시스템을 강간(?)하던 과거 구조 보다, 훨씬 안전하게 사용할 수 있다. 시스템 자원을 변경하려면,, 어떻게 하든 저렇게 UAC가 뜨기 때문에, 철저하게 막는다고 할 수 있다.

매번 불필요할 정도로 저런 화면이 뜨게 되면 성질이 날듯… 물론 Windows 7은 Windows Vista 보다 저런 화면이 덜 뜬다. 그나마 사용자 배려를 하기 위해 최소한으로 중요하다가 판단되는 시스템 영역이 아니면 일단 저런 화면 없이 진행은 계속 된다. 하지만, Active X의 경우 실행할 때 마다 위와 같은 화면이 뜰 때 슬슬 사람들은 승질 내기 시작한다. 설치 때 마다 물어보고, 뭔가 수정할 때마다 물어보고, 이런 저런 팁들을 적용하려고 할 때 마다, Run as Administrator ( 관리자 모드로 실행 )을 하지 않으면 안되고..

시스템이 털리던 말던, 불편함을 감소시키고 싶다면 아래의 방법을 사용해보는 것도 좋다.

( UAC 옵션에 들어가서 묻지 않기로 하는 방법이 있지만, 그 방법 보다는 필자가 제시한 방법이 가장 XP에 근접한 방법이다. UAC 옵션에서 아예 묻지 않기로 하는 경우, 대개의 경우에는 되기도 하지만, 관리자 모드로 실행하기를 하지 않는 경우 제대로 실행 안되는 경우도 자주 발생된다. )

1.임시 계정 만들기.

먼저 사용자 관리에 들어가서 임의의 사용자를 만든다. 물론 관리자 권한을 갖는 사용자를 만든다.

위의 그림대로 한다면 test 라는 계정이 생기데 되는데, 이 계정으로 로그인을 한다.

2. 임시 계정으로 로그인.

Log Off(로그 오프)를 한 뒤, 이제 test 계정으로 로그인 한다.

3. Administrator 계정 활성화.

기본적으로 Windows를 설치하면 Administrator 계정이 비활성화 되어 있는데, 이 계정을 활성화 시켜야 한다.
계정 관리자를 띄워야 하는데, 아래와 같은 순서로 접근한다.

내 컴퓨터에서 우클릭을 해서 컨텍스트 메뉴를 띄운 후, 컴퓨터 관리를 선택한다.

왼편 트리에서 로컬 사용자 및 그룹을 선택하고, 그 하위에 있는 사용자를 클릭하면 오른쪽에 Administrator 계정을 볼 수 있다. 자세히 보면 사람 아이콘 앞에 화살표가 아래로 향한 아이콘이 덧붙여져 있다.

이제 Administrator 에서 우클릭을 한 뒤, 속성 창을 연다.
그리고 그 안에 “계정 비활성화” 체크 부분을 꺼준다.

그리고 난 뒤, 재 부팅을 해서 Administrator로 로그인을 한다.

4.정리

장황하게 캡쳐화면과 설명을 난무 했지만, 실질적으로는 Administrator라는 계정을 활성화 한 것이 전부다.
이 계정을 활성화 한 뒤에 해당 계정으로 로그인 하면, 무조건 관리자 모드다.

보안에서는 꽝이지만, 최소한 UAC등의 권한 문제로 인한 문제점은 깡그리 사라진다.

덧붙여 만일 자신이 원하는 계정이름으로 사용하고 싶으면, 저 Administrator라는 이름을 변경하면 된다.
변경하는 방법은 3번에서 나온 화면에서 Administrator위에서 우 클릭 한 뒤, 이름 변경을 하면 된다.

원하는 이름으로 변경하고, 재 시작하면, Administrator가 아닌 자신이 변경한 이름으로 로그인이 가능하다.

인터파크 쇼핑을 이용하는 아시는 분..

다음 링크를 통해 제품을 보았는데..

http://www.interpark.com/product/MallDisplay.do?_method=Detail&viewTp=preview&sc.shopNo=0000100000&sc.prdNo=2379238139&dispNo=008001

제목줄은 기가 비트라 적고...

내용은 10/100 임..

황당...

낚이지 마시기 바랍니다.. 그저...

지금 저 링크의 상품은 조만간 폭파되겠지요( 증거 인멸.. 현재는 판매 중지 상태! )

외국 사이트를 찾아보니, How to 라는 항목으로 존재했다.

http://www.howtoforge.com/how-to-install-vmware-tools-on-pfsense-freebsd

문제는 32bit 버전에 pfSense 과거 버전 기준으로 작성된 것 같았다.

그래서 이번에 설치했던, pfSense 2.1 x64용 안정화 버전을 가준으로 수정한 내용을 정리한다.
pfSense 2.1은 FreeBSD 8.3 기반으로 구성되어 있어 이에 맞게 스크립트 실행을 변경한다.

설치방법

제일 먼저 콘솔을 띄운다. SSH도 좋지만, 이왕 방화벽 22번 포트를 연결하기 보다, 차라리 Console을 직접 연다.

그리고 난 뒤, 콘솔로 들어가 다음 명령들을 입력한다.

setenv PACKAGEROOT "ftp://ftp.freebsd.org"

원본 사이트에서 일부 다른 부분이 바로 이 부분이다.

setenv PACKAGESITE "ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.3-release/Latest/"

이제부터 VMTools를 설치하기 위한 관련 패키지들을 설치한다.

pkg_add -v -r perl

pkg_add -v -r compat6x-amd64

cd 
mkdir tmp2
mkdir tmpp
mount_cd9660 /dev/acd0 /tmp2
cd /tmp2

마운트 되었으면 vmtools 원본을 복사하고 압축을 푼다.

cp vmware-freebsd-tools.tar.gz /tmpp
cd /tmpp
tar -zxvf vmware-freebsd-tools.tar.gz
cd vmware-tools-distrib/

이제 compat6x 라이브러리들을 준비해야 한다. VMWare에서 사용되는 라이브러리들인데, 기본적으로는 처리되지 않는 것들이기 때문에, 수작업으로 연결한다.

ln -s /usr/local/lib/compat/libm.so.4 /lib
ln -s /usr/local/lib/compat/libc.so.6 /lib
ln -s /usr/local/lib/compat/libthr.so.2 /lib

실행하기 위해서는 설치 프로그램 스크립트를 실행형태로 만듭니다. 그리고 실행합니다.

chmod +x vmware-install.pl bin/vmware-config-tools.pl bin/vmware-uninstall-tools.pl
./vmware-install.pl

실행하면, 무언가 메시지들이 뜨면서 입력을 대기합니다. 특별히 변경할 내용은 없으므로, 계속 Enter를 치고 넘어가면 자동적으로 설치가 되면서, 맨 나중에 Enjoy 어쩌고 저쩌고가 뜨면 완료된 겁니다.

이제 자동 실행이 될 수 있도록 수정합니다

echo '#\!/bin/sh' > /usr/local/etc/rc.d/000-ldconfig.sh 
echo '/sbin/ldconfig -m /usr/local/lib/compat' >> /usr/local/etc/rc.d/000-ldconfig.sh
chmod a+x /usr/local/etc/rc.d/000-ldconfig.sh 

이제 작업했던 파일들을 삭제하고 reboot를 한다.

cd /
rm -r /tmpp/
rmdir tmpp
shutdown -r now

정리

분명 VMTools에서 제공된 드라이버들은 업데이트 된 것 같다.
다만, 현재 자동으로 VMTools가 안떠서 현재는 더 고민 중이다. ( HOST에서 감시 도구가 떠줘야 관리를 하는데, 현재 뜨지 않아서 관리모드가 안되고 있다. ) 몇가지 더 테스트를 해보고, 되는대로 업데이트 할 예정이다.

지금 빌드 서버로 HUDSON을 쓰고 있다.
상당히 오랜동안 쓰다 보니 나름 익숙해진 부분도 많아서 지금은 계속 HUDSON을 사용하고 있다.
그런데, 문제는 이 HUDSON에서 플러그인으로 제공하는 SVN 이 버전 문제를 앓고 있다는 점이다.
체크인을 해서 분명 SVN내 버전이 올라갔는데도 불구하고, HUDSON에서 새버전에 따른 트리거를 발동하여 자동 빌드가 들어가지지 않고, 계속 대기를 타고 있었다.
처음에는 HUDSON 자체의 문제로 인지하고, 각종 업데이트를 했지만, 요지 부동!.

결국 찾아낸 것이 폴링에 대한 실행 결과를 보니 나오는 문제가 있었다.특히 SVN서버가 1.8 버전 일때, 다음과 같은 형태의 오류가 폴링 오류로 잡히게 된다.
(현재 HDUSON은 정상 작동하여 Polling 오류 메시지를 찾을 수 없어, 대신 Jenkis에서 발생된 예제를 띄웁니다. 약간 오류의 메시지가 다르게 나타나지만, 유사한 오류 입니다.)

Received SCM poll call on  for NGCS on Oct 21, 2013 11:26:09 AM
ERROR: Failed to check repository revision for [..]/trunk
org.tmatesoft.svn.core.SVNException: svn: E210004: Number is larger than maximum
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:400)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readTuple(SVNReader.java:288)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:241)
    at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:272)
    at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.read(SVNRepositoryImpl.java:1290)
    at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.info(SVNRepositoryImpl.java:1203)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:65)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
    at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
    at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
    at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
    at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
    at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1122)
    at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:71)
    at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
    at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
    at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1278)
    at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
    at hudson.scm.SCM.poll(SCM.java:373)
    at hudson.model.AbstractProject._poll(AbstractProject.java:1567)
    at hudson.model.AbstractProject.poll(AbstractProject.java:1490)
    at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:439)
    at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:468)
    at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)
Caused by: svn: E210004: Number is larger than maximum
    at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
    at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
    at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
    at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:399)
    ... 33 more
Done. Took 0.1 sec
No changes

문제 원인

이 문제는 HDUSON의 문제가 아닌 HUDSON의 SVN 플러그인의 문제이다.
플러그인이 애석하게도 SvnKit 1.7 기반으로 만들어져 있어서, SVN의 서버가 1.8 이상인 경우 버전 정보만 가져올 때 잘못된 값을 가져와서 발생된 문제이다. 물론 직접 디버깅을 걸어 확인한 사항은 아니지만, 최소한 위의 Exception 정보 및 해당 내용을 Google로 검색해보면 대략 답이 나온다.

결국 SVN 플러그인을 업그레이드 하던가, 1.7로 낮추던가 둘중 하나를 택해야 한다.
하지만 현재(2014년 3월 10일)까지 SVN 플러그인은 여전히 1.7까지만 지원하고, 아직도 업그레이드가 안되고 있다.

결국 내가 가진 SVN 서버의 버전을 낮추는 방법 밖에는 없다.

SVN 1.7 버전 다운로드.

현재 SVN 서버는 Windows에서 실행하고 있다. Bitnami의 Redmine 스택을 설치하면 Subversion 폴더가 있는데, 그안의 내용을 일부 수정해서 독자적으로 서비스로 등록해 사용 중이다. 그런데, 최신 스택이다 보니, 이 Subversion도 무려 1.8.5 버전.
현재 이 버전으로 돌리니 당연히 HUDSON이 지원안되는 것이였다.
그래서 이 서버 파일들을 모조리 1.7용으로 바꿔야 한다.

SVN 실행 파일들을 획득하는 방법은 다양하게 있지만, 필자는 CollabNet에서 다운 받았다. ( http://www.collab.net/downloads/subversion ) 물론 사이트 Front에 들어가면 1.8 부터 노출되어 있으니, 패스.

맨 아래쪽에서 제공하는 링크인 http://www.collab.net/downloads/svn-other 로 이동해서, 1.7.16 버전을 다운 받았다. 당연히 x64 서버이니, x64 버전을 다운 받았다.

받은 파일을 실행해서 적당한 Folder에 설치했다.( D:\svn ). 그 안에 보면 각종 dll과 실행 파일들이 있는데, 바로 이 파일들이 1.7용 SVN이 된다.

버전 이력 마이그레이션

먼저 SVN 서비스를 돌리고 있다면 먼저 중지시킨다. 로컬이라면 SVN을 접근하는 프로그램들을 모두 중지시키도록 하자. 그리고 난 뒤, 실행 파일을 덮어쓰기 위한 준비작업을 실행한다. 그냥 실행파일만 바꾸게 되면, SVN 저장소의 DB 포멧이 달려저서 자칫 SVN DB가 망가지거나, Client에서 접근이 어렵다. 먼저 SVN을 백업 하도록 한다.

svnadmin dump [subversion DB 파일들이 있는 경로] > backup.bak

이 처럼 해서 먼저 모든 버전들 백업을 확보한다.

백업이 완료되었으면 이전 DB는 삭제한다.

이제 다운로드 받은 1.7 버전을 덮어써준다.

다시 1.7 버전의 svnadmin으로 DB를 생성한다.

svnadmin create [subversion DB 경로]

마지막으로 백업 받은 내용을 DB에 부어주도록 한다.

svnadmin load [subversion DB 경로] < backup.bak

이제 중지 시켰던 서비스를 다시 실행한다.

정리

요즘은 Hudson 대신 Jenkis를 주로 쓰는 추세인지, HDUSON 자료를 찾다보면 Jenkis가 훨씬 많은 레퍼런스를 보여준다. 하지만, Jenkis 자체의 태생이 HUDSON이여서 인지, 실제 구성하는 방법은 50보 100보.

여튼 이번에 SVN 이슈 때문에, 빌드는 계속 밀렸었고, 당황했는데, 간신히 살린 것 같다.

이번에 좀 뻘짓하면서 개발 환경 재정리하면서 빌드서버 까지 정리 완료 했으니, 그간 미룬 작업들 까지 모조리 정리해야 겠다. 나중에 뻘짓 안하기 위해 귀찮더라도 기록을 남긴다.

자료 출처

2CPU의 가상화 게시판 : http://2cpu.co.kr/bbs/board.php?bo_table=vm
XPENology Forum : http://xpenology.com/forum/index.php
DomStation 블로그 : http://www.domstation.com/opware-bootstrap-and-open-vm-tools-installation/
Idiot's Guide to DSM 4.2 and ESXi 5.1.docx : http://depositfiles.com/files/virzefc1a

2CPU 장터를 통해 XW4600을 구하게되었고, 무사히 Esxi 5.5를 설치했다.
( 벤더 제품 중 가장 Native 하다고 생각되는 HP. 역시 큰 문제 없이 한번에 Esxi 5.5를 설치할 수 있었다.)

테스트를 위한 Windows Server를 설치하고 나니, 왠지 내부적으로 사용할만한 NAS가 필요했고,
이ㅔ XPEnology ( Synology OS를 커스텀화한 NAS 운영체제)를 설치하게 되었다.
편리한 UI 와 Extention이 가능한 추가 기능들은 매우 매력적일 수 밖에 없었기에, 자연스럽게 설치를 시작하게 되었다.

생각보다 진입점이 높아서(구축사례가 많지만, 기록물이 적은듯...) 검색어에 잘 걸리지 않아, 결국 2CPU를 통해 하나씩 접근해보았고, 그에 맞춰 성공한 사례를 기반으로 새로 하나 더 만들면서 기록해 본다.

1. 준비하기.

먼저 XPENology 파일들은 모두 7zip으로 압축되어 있다.
7zip 부터 설치해놓자. ( http://www.7-zip.org )

다음은, Esxi용 이미지가 필요하다.
처음에는 설치용 미디어만 있으면 될 줄 알았으나, 그 방법은 직접 PC 혹은 서버에 설치할 때이였고, 실제로는 Esxi용으로 별도로 만든 이미지가 필요했다. 이 파일은 다음 경로에서 다운이 가능하다.
http://xpenology.trantor.be/esxi/

다운을 받으면 7zip으로 압축된 파일을 다운 받는다. 이 파일을 받아 압축을 풀면 VMDK 파일이 생기는데, 이 파일이 가상머신에서 사용될 HDD 디스크 파일이다. 일단 이 파일을 저장해 놓는다.
( 현재 여기서 사용한 파일의 파일이름은 synoboot_trantor_3810_esxi_v1.1.vmdk 이다. )

그리고, 실제 XPENology를 구동하기 위한 프로그램들을 담은 Patch 파일이 필요하다.
이 파일은 배포본을 다운 받으면 된다.

파일을 다운로드 해서 압축을 풀면, 두개의 파일이 나오는데, 그 중 PAT 파일이 필요하다. 이 파일도 보관하자.
( 현재 여기서 사용한 파일의 파일이름은 XPEnology_trantor_v1.0_DSM_DS3612xs_3810.pat 이다. )

마지막으로 Synology Asist 라는 프로그램을 다운 받는다.
XPENology를 설치했을때, 어디에 설치되어 있는지 부터, 최초 구성작업을 이도구를 통해서 작업할 수 있어 매우 편하다. 경로는 http://global.download.synology.com/download/Tools/SynologyAssistant/4359/Windows/SynologyAssistantSetup-4.3-4359.exe 이다.

설치용 프로그램이므로 다운받은 뒤 실행해서,  반드시 설치해 놓도록 한다.

2. VM 만들기.

이제 ESXI 서버에 접속하자. 콘솔을 통해서 업로드하고, CLI 입력들을 해서 처리할 수 있겠지만, 편한 GUI를 사용하여 작업할 수 있기 때문에, 여기서는 GUI 기반으로 설명한다. ( 사실 필자도 CLI는 잘 사용하지 못한다. )

vSphere Client를 통해 Esxi 를 접속한다.

서버가 표시되었을 때, 서버에서 Context Menu를 띄워 "New Virtual Manchine"으로 들어간다.

Configuration Type은 Custom으로 한다

적당한 이름을 정한다.

VM 파일들이 저장될 위치를 선정한다. 나중에 VM Image를 올릴 위치이므로 어디다 VM을 만들었는지 기억해 놓도록 한다.

가상 머신의 버전을 선택하는 화면이 나온다.
여기서는 호환성 문제가 걸리지만 않는다면, 최대한 최신 설정으로 진행한다.

설치할 게스트의 운영체제를 선택하는 화면이 나온다.
여기서는 Linux로 하고, 2.6.X 버전의 리눅스를 사용한다고 체크한다.

CPU 설정은 취향대로 하면 된다.
다만, 다양한 기능들을 사용할 예정이면, Core 갯수를 늘리는 것도 좋다.
여기서는 1 이지만, 앞서 설정했던 XPEnology에서는 Core를 2개로 잡았다.

메모리 설정하는 부분이다.
이 역시 CPU 처럼 고성능의 작업이 필요하면 용량을 늘리도록 한다.
다만, 굳이 1G 이상을 안잡아도 생각보다 성능이 훌륭하게 나오는 편이다.

네트워크 설정 화면이 나온다.
각자 ESXI가 구성된 형태에 따라 알아서 잡도록 한다.

SCSI 컨트롤러 선택화면이 나온다.
Synology가 연결되는 형태의 SCSI 컨트롤러로 바로 잡히려면, 맨 아래 쪽에 있는 VMWare Paravirtual을 선택하도록 한다. 다른 옵션들로 연결이 잘 안되는 것 같다. ( XPENology에 해당 컨트롤러 드라이버가 없는 듯 싶다. )

저장소로 사용할 디스크를 생성한다.
실제적으로 XPENology 프로그램 및 저장장소로 사용될 공간을 잡는다.
여기서는 적당히 120G로 설정했다. 이 설정은 VM 설정으로도 추가적으로 잡을 수 있으므로, 적당히 잡도록 한다.

이제 Summary가 나왔으면 Finish를 누르도록 한다.

3. VM 구성

자 기본틀은 완성되었다. 이제 기본으로 제공한 VM을 이용해 XPEnonlogy를 구축하기 위한 작업을 한다.

먼저 앞서 다운 받은 vmdk 파일을 저 VM이 위치한 폴더에 업로드한다.
이를 위해서는 Brower DataStore를 띄워야 한다. 이 위치 정보는 앞서 VM을 생성할 때의 위치에 해당하는 저장소를 열도록 한다.

Datastore Browser를 띄웠으면 해당 폴더를 열도록 한다.

이제 아까의 VMDK 파일을 업로드 한다.

업로드가 완료되었으면 이제는 해당 VM의 Edit Setings 메뉴를 띄워 Properties 창을 띄운다.

VM 의 Properties 창이 떴으면 Hardware 탭에 있는 Add 버튼을 클릭하고, 새로 뜬 창에서
Hard Drive를 선택하도록 한다.

이제 업로드한 HDD를 연결한다. "Use an exsisting virtual disk"를 선택한다.

자 이제 업로드한 파일을 선택하고 Open을 한다.

IDE 0:0 로 되어있는지 확인하고 넘어간다.

완료 처리한다.

4.XPENology 설치

이제 XPENonlogy를 위한 VM 작업은 다 끝났다. 이제 VM을 실행하도록 한다.
실행하면서 Console 창을 띄워보면 뭐라 뭐라 Linux 부팅이 되고 최종적으로 "Diskstation login:" 이라는 문구로 끝날 것이다.

만일 띄우지 못했다면, Booting 순서 문제일 수 있으니, 재부팅을 한 뒤, 바이오스에 진입(F2 로 들어감)하여, 부팅 순서가 SCSI 보다 IDE HDD가 먼저 나올 수 있도록 한다. ( 부팅이 한순간이므로 부팅되자 마자 매우 빠른 F2 연타가 필요할 수 있다. )

이제 XPESynology를 구성하도록 한다. 이를 위해서 앞서 설치한 Synology Assist를 사용한다.
Synology Assist 프로그램을 실행한다.

그러면 자동적으로 설치된 XPENology를 볼 수 있다.
(만일 볼 수 없다면, 같은 네트워크 대역에 있는지 확인하고, 해당 XPENology VM이 제대로 떴는지 등을 확인하도록 한다. 예를 들면 Synology Assist가 실행되는 PC의 IP는 192.168.0.101 인데, XPENology의 IP는 192.168.102.8 인 경우 192.168.0.X 와 192.168.102.X는 서로 대역이 다르므로 직접 연결하여 찾지 못한다. 단순하게 말하자면, 같은 공유기 내에 있어야 된다는 의미.)

자, 연결된 개체서 Context Menu를 띄워 설치를 클릭한다.

이제 설정 마법사가 뜬다.
설치 파일 경로를 입력해달라는 위치에, 앞서 다운 받은 PAT 파일을 연결한다.

PAT를 정상적으로 연결했으면, 이제는 서버 정보를 입력한다.
여기서는 admin의 암호를 설정하고, 서버 이름등을 설정하면 된다.
admin 암호만 입력해도 된다. ( 서버이름의 기본값이 DiskStation 이다. )

SHR 볼륨 생성에 대한 체크가 된 상태로 하면 경고 창이 뜨는데, "확인" 누르고 진행하도록 한다.

이제 네트워크 설정을 한다. 가급적이면 IP를 고정해서 설정하도록 한다.
그래야 접근할 때 쉽기 때문이다.

그러면 설치 진행 화면이 나오는데, 큰 문제가 없으면 체크가 다 표시되면서 종료 버튼이 나오는데,
그 버튼을 클릭하면 된다.

5. VM Tools 설치.

사실 여기까지만 오면 완료되긴 했지만, 문제는 Esxi 서버에서 이 XPENology 서버를 끄질 못한다. 즉 직접 XPEnology를 콘솔로 접근하던가 해서 강제로 꺼야 된다는 말. 전원 자체를 내리는 Power Off는 되지만, Shutdown이 안된다는 의미이다.

그래서 ESXI에서 Shutdown Guest 제어가 되려면 VM Tools를 설치해야 한다. 문제는 ESXI에서 제공하는 VM Tools를 설치하기가 쉽지 않은데다가, 이 XPENology와 호환이 안된다. 그래서 다른 방식으로 진행해야 한다.

먼저 Putty 같은 telent 접속 프로그램이 필요하다. ( http://www.chiark.greenend.org.uk/~sgtatham/putty/ 설치용 프로그램이 아니므로 실행 파일만 받아서 실행하면 된다. )

실행하면 주소 창이 뜨는데, 그 안에 XPEnology의 주소를 입력한다. ( 앞서 XPENology 설치할 때의 IP 주소)

인증서 부분의 Warning이 뜨는데, Yes를 눌러 진행한다.

그러면 콘솔 접속 화면이 뜨는데, ID는 root 로, 암호는 앞서 만든 admin의 암호를 넣는다.

이제 명령 창과 함께 명령어들을 잘 입력하면 된다.

1. 먼저 temp 디렉토리로 이동한다.
   

   cd /volume1/@tmp

2. bootstrap 을 다운로드 받는다.
   

   wget  http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

3. 다운 받은 bootstrap 파일을 실행 파일로 만든다.
   

   chmod +x syno-i686-bootstrap_1.2-7_i686.xsh

4. .xsh 파일을 실행한다.
   

   sh syno-i686-bootstrap_1.2-7_i686.xsh

5. 이제 실행했던 스크립트 파일을 삭제한다.
   

   rm syno-i686-bootstrap_1.2-7_i686.xsh

6. PATH의 경로를 변경하는 작업을 한다. 이를 위하 vi를 띄운다.
   

   vi /root/.profile

7. vi에서 다음과 같이 입력하여 PATH의 문자열을 바꾼다.
   

   :%s/PATH=/PATH=$PATH:/

8. vi에서 다음과 같이 입력하여 저장하고 닫는다
   

   :wq!

9. 재부팅한다.
   

   reboot

10. 재부팅이 완료되었으면, 다시 putty를 실행해서 다시 로그인해서 연결한다.
11. 이제 ipkg를 이용해 내부 패키지를 정리한다.
    

    ipkg update
    ipkg upgrade

12. 다시 temp 디렉토리로 이동한다.
    

    cd /volume1/@tmp

13. open vm tools를 다운 받는다.
    

    wget http://users.skynet.be/synology/i686/syno_vmware_kernel_mod_x86_64_3.2.30.zip

14. 다운 받은 파일의 압축을 해제한다.
    

    unzip syno_vmware_kernel_mod_x86_64_3.2.30.zip

15. 압축이 풀린 경로로 들어간다.
    

    cd syno_vmware_kernel_mod_x86_64_3.2.30

16. sh용 파일을 실행 가능하게 만든다.
    

    chmod +x S37vmware.sh

17. sh용 실행한다.
    

    sh S37vmware.sh start

18. 이제 Tools의 실제 동작하는 파일들을 설치한다.
    

    ipkg install http://users.skynet.be/synology/i686/open-vm-tools_9.2.3-1031360-1_i686.ipk

19. vmtools가 자동으로 실행될 수 있도록 구성 준비한다.
    

    cd /opt/etc/init.d/

20. 자동 스크립트를 다운 받는다.
    

    wget http://www.domstation.com/wp-content/uploads/2014/01/S22open-vm-tools-v1.1.zip

21. 스크립트의 압축을 푼다.
    

    unzip S22open-vm-tools-v1.1.zip

22. 스크립트를 실행 가능하도록 만들어 준다.
    

    chmod +x S22open-vm-tools.sh

23. 다운 받은 zip 파일은 삭제하고 reboot를 한다.
    

    rm S22open-vm-tools-v1.1.zip
    reboot

명령 줄을 입력할 내용을 쭉 나열해서 그렇지, 사실 별 내용은 없다. 이제 root 되고 난 뒤, 완전히 부팅되었으면, Esxi 관리도구에서 해당 VM을 종료해본다. 이제는 제대로 종료가 되는 것을 확인할 수 있다.

정리.

사실 모든 정보는 준비되어 있었고, 자료도 있었지만, 여기저기에 단편적으로 나뉘어 있는데다가, 대부분 영어권 자료다 보니 쉬이 적용을 못하고 있었다. 하지만, 막상 해보니 큰 어려운은 없었던것 같다.

나중에 2~3T 짜리 HDD가 들어오면 용량을 넉넉히 붙여서 내 개인 저장 장소로 활용해보도록 해야 겠다.