'분류 전체보기'에 해당되는 글 1249건

요즘 하루 하루 업무를 하면서 내가 무슨일을 하고 있는지 기록을 남기고 싶었다.
업무 뿐만 아니라, 간단하게 주고 받은 개인적인 정보라든가, 요청 내용, 그 외에 상황들
일기장 까지는 아니지만, 그 순간 잠깐 기록하고 싶은 마음이 들었다.
단! SNS와는 전혀 다른 방향으로,
뭔가 남에게 노출되는건 정말 꺼리는 정말 개인적인 정보들로만 남발된!
그런 메모!

그래서 마이크로소프트의 원노트도 꺼내보고, 에버노트도 꺼내보며, 포스트잇 프로그램들도 깔아서 써보고, 그외 각종 노트, 메모 프로그램을 깔아서 써보았다. 다양한 사용자들과 다양한 욕구들을 만족 시키기 위해서 여러가지 기능들이 남발하거나, 겹쳐져 존재 했다.

매번 제목 넣으라는 것도 마음에 들지 않았고, 중구난방 화면 가득 붙여져 나가는 포스트잇 스타일의 메모도 탐탁치 않았다. 뭐 종류 별로 정리해서 담으라고 각종 분류 도구를 주는 것도 탐탁치 않았다.

그냥 몇줄의 메모를 남기고 싶은데, 매번 쓸 때마다 제목을 적으라고 해서 내 생각을 매번 요약해야 되니 이것도 일.
또, 내 생각이 어느 순간은 업무, 어느 순간은 취미, 어느 순간은 집안 일 이렇게 바뀌는데, 매번 그 순간 순간 마다 기록을 하다 보니, 결국 분류 실패로 메모들이 정리가 안되었다. 게다가 포스트잇 스타일은 화면 가득 방해 놓는 것도 영, 싫었다.

난 그저, 그냥 쓰고 싶을 뿐인데 말이다.
순간 생각 나거나, 순간 기록을 위한 그냥 텍스트로 입력해서 저장하고,
나중에 날짜나 시간대 별로, 쭉~ 나열해 볼 수 있는 그런 단순한 메모장이 필요했다.

그를 위해서 만들어봤다.

프로그램 사전 정보

• 프로그램 이름 : KNOIE Memo
• 용도 : 개인 기록 저장용.
• 권장 사항 : Windows XP 이상,
                  RAM 1G 이상,
                  HDD 10M, .
                 NET Framework 4.0 이상

설치 방법

Click Once로 배포를 간단하게 만들었다.

http://neohind.cafe24.com/deploy/memooff

사이트에 접속해서, “Install” 혹은 “설치” 버튼을 눌러
설치 파일을 다운 받거나 직접 실행하면 된다.

가난한 개발자다 보니, 별도 배포용 인증서가 없다. ( 년 10~20만원을 지불해야 하는데, 무료 배포 버전에 무슨.. 인증서를 -_-;; )
그래서, “알 수 없는 배포자”로 나오기 때문에, 마치 설치 금지 처럼 나오기는 하지만, 대충 무시하고 설치하면 된다.
( 다만, .NET Framework 가 없으면 설치도 안되고, 실행도 안된다. -_-;;; )

사용법

정상적으로 설치되고 실행 되었으면, 오른쪽 아래 트레이 아이콘이 나온다.

이 프로그램은 모두 이 트래이아이콘에서 출발한다.

1. 메모기록

여기서 단순 클릭을 하면 메모 입력 창이 뜬다.

적당한 날짜와 시간을 설정하거나, 그대로 둔 뒤, 텍스트 박스 안에 로그를 넣는다.

다 썼으면 “Upload” 버튼을 누른다.

그러면 자동으로 메모장 화면이 닫힌다.

끝.

2. 기록 내용 보기

트레이 아이콘에서 오른쪽 버튼을 누르면 나오는 메뉴에서, View List를 클릭한다.

그러면 다음과 같은 창이 뜬다.

오늘 날짜를 기준으로 모든 기록 내용이 날짜 순으로 나오게 된다.

처음 날짜는 시작 일자, 나중 날짜는 끝 일자이다. 적당히 선택한 뒤, 조회를 누르면 해당 일자 사이의 모든 기록을 볼 수 있다. 성능 및 표시 방법의 문제로 인해 메모 내용이 모두 펼쳐지진 않는다.

원하는 기록을 클릭하면 자동으로 펼쳐지는 정도만 된다.

3. 종료

트래이 아이콘에서 오른쪽 버튼을 클릭해서 나오는 메뉴에서

Exit 를 선택하면 끝!

정리

이 프로그램을 사용하는데 필요한 추가적인 내용은 다음과 같다.

• 모든 데이터는 내 문서 폴더에 있는 knoiememo.db 파일에 저장된다.
  ( 반드시 이 데이터베이스 파일을 백업해야 한다.)
• 쓰기 창을 띄웠는데도 화면에 나타나지 않은 경우 ALT + TAB을 눌러 아이콘을 선택하면 된다.

지금은 시작 프로그램이기 때문에, 아직은 개선할 사항이 많다.
현재 버전에서 개선해야 할 점이나, 추가해볼 필요가 있는 내용은 다음과 같다.

• 첨부파일 기능
• DB 파일 자동 백업 기능 ( 클라우드 등 )
• DB 파일 통합 기능
• 암호화 처리
• RTF 형식의 입력 처리

일단은 이렇게 생각은 했지만, 사실 당장 내가 쓰는데는 지장이 없어 시간이 될 때 하나씩 업데이트 할 예정이다.

만일 사용 중 버그가 있으면 댓글을 통해 알려주면 수정해서 업데이트 할 예정이다.

각종 서버상에서 남는 로그는 일반적으로 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 이슈 때문에, 빌드는 계속 밀렸었고, 당황했는데, 간신히 살린 것 같다.

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