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

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가 들어오면 용량을 넉넉히 붙여서 내 개인 저장 장소로 활용해보도록 해야 겠다.

Visual Studio 안에 있는 Setup Project로 간단한 설치 프로그램을 만들곤 한다.
(복잡한 설치 구성이 필요 없는 경우 이 설치기능은 참 편하다)

그런데, 프로그램을 일부 수정해서 다시 말아서 배포하는 경우가 있다. 
이때  새로 만든 설치 본으로 설치하려면 다음과 같은 메시지가 떠서 상당히 곤혹스럽게 만들 때가 있다.

즉, 이미 다른 버전이 설치되어 있어서 설치가 불가능하므로, 이전에 설치된 버전을 삭제한 후, 다시 설치하라는 의미이다. 업그레이드와는 다른, 즉 이전 버전인지 신규 버전인지를 판단하지 못하는 경우를 의미한다.

그럼 이 문제는 어떻게 해결 해야 하는 걸까?
고민 중에 다음과 같은 문서가 있는 링크를 찾았다.

What are Upgrade, Product and Package Codes used for?

MSI를 구성할 때, 제품만의 고유한 버전을 위해 3가지 값을 사용한다.

Update Code, Product Code, Package Code.

이 세가지 값을 이용하여, 설치된 프로그램의 종류, 버전 등을 구분하여 제공하게 된다. 즉 프로그램 설치/삭제/수정 등의 모든 작업을 운영체제에서 처리할 때, 사용자들이 알아보는 문자열 대신 일종의 일련 번호로써 역할을 하게 되는 것이다. 여기서는 해당 하는 값들과, 그 역할들을 위의 링크에 있는 페이지 내용을 기반을 그대로 옮겨 적어 기록한다.

각 코드 값은 GUID라는 고유 값을 문자열 형태로 나타내도록 되어 있다.
( 예를 들면 {FB23FA93-3A96-4C91-B441-042F22C88BA4} 과 같은 값 )

MSI에서의 UpgradeCode란?

Upgrade Code란, 만든 Application을 대표하는 값을 의미한다. 같은 프로그램은 아니지만, 하나의 계열을 이루고 있을 때, 이 코드가 사용된다. 예를 들면 MS Office 제품군 과 같은 계열로 구성되었을 때 같은 제품이라는 의미를 갖게 해주는 것이다. Office 2010 을 예로 들었을 때, Office 2010을 설치하면 Word 2010, Excel 2010 이런 제품들이 설치되게 된다. 이것을 하나로 아우르는 표현을 할 때, Word 2010도, Excel 2010도 같은 Upgrade Code를 갖게된다.

만일 Upgrade Code가 달라지는 경우, 아예 프로그램이 다르다! 라고 인식하게 된다. 그러므로, 완전히 틀려지는 제품이 아닌 경우에는 이 코드의 값을 변경하지 말아야 한다.

MSI에서의 Product Code란?

Product Code란, 같은 프로그램인데, 언어나, 버전이 틀린 경우 그 구분을 위해 제공되는 값이다. 즉 프로그램이 업그레이드를 했거나, 언어가 다른 경우 이 코드 값을 달리해서 적용해야 한다. 이 코드 값을 이용해 실질적인 업그레이드나 추가 작업을 수행하게 된다.

MSI에서의 Pakage Code 란?

앞서 설명한 Upgrade Code 및 Product Code와는 다르게, MSI 파일 자체에 대한 구분을 위한 버전이다. 작은 설치용 프로그램인 경우에는 크게 문제가 없지만, 만일 여러가지 구성요소들을 구분지어 설치파일을 만든 경우 MSI 구성요소들이 달라지게 된다. 즉 각각의 설치 구성요소 별로 구분을 짓기 위해서 이 Package Code를 구성하게 된다.
이 부분은 프로그램의 업그레이드 보다, 패치와 같은 단위 구성요소의 업데이트를 할 때 이 값을 이용해서 설치파일을 구성하게 된다.

각 코드 값을 이용한 프로그램 추가/삭제 동작 정리

사실 단순하게 코드 값을 변경해서 이런 저런 설치 동작을 하면 쉽게 이해가 되긴 하지만, 의외로 Setup 프로그램을 만들어 매번 등록 삭제 하려면 정리가 쉽진 않다. 그래서 각 코드의 변경에 따라 어떻게 동작하는지를 정리했다.
(이 내용은 앞서 언급한 링크의 내용을 참고로 구성했다

1. 같은 Product Code에 같은 Package Code로 된 MSI를 설치하려는 경우 “수정” 혹은 “삭제” 동작을 수행하게 된다.
2. 같은 Product Code에 다른 Package Code로 된 MSI를 설치하려는 경우 실행되지 않는다. 이 경우 맨 처음 필자가 겪은 메시지창이 뜨면서 설치가 되지 않는다.
3. 다른 Product Code에 같은 Package Code로 설치하는 경우 “수정” 혹은 “삭제” 동작을 수행하게 된다. 만일 RemovePreviosVersion이 True인 경우 기존 버전을 삭제하고 재설치를 수행하게 된다.
4. 다른 Product Code에, 다른 Package Code로 설치하는 경우, 인스톨러는 완전히 다른 제품으로 인식해서 새로 설치하게 된다. (중복 설치)

즉 필자 처럼 단순 업그레이드로 구성하려면, Setup Project 옵션의 RemovePreviosVersions를 True로 한 뒤, 새로운 Product Code를 구성해야 한다.

일단, 자동 빌드 구성에 위의 내용을 기반으로 해보니, 별다른 오류 없이 제대로 설치가 되었다.
나중에 Patch 판을 만드는 방법도 고민해봐야 겠다.

앞의 포스트에서 log4net의 동적 설정에 대해서 이런저런 이야기를 펼쳤다.

이 기준을 가지고 몇 가지 수정하면서 간단한 설정용 클래스를 만들었다.
물론 Rolling File에 대한 설정만 되는 간단한 구조이기 때문에 추후 지속적인 업데이트가 필요하다.
다만, 프로젝트들을 하면서 매번 코드 덩어리를 붙여넣기에 한계가 있어, 아예 클래스로 구성해봤다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Text.RegularExpressions;

namespace net.knoie
{
    public class LoggerSettings
    {
        private string m_sLogFullFilename = string.Empty;

        public  static LoggerSettings Current
        {
            get;
            private set;
        }

        public static void CreateInstance(string sLogFullFilename)
        {
            Current = new LoggerSettings(sLogFullFilename);
        }

        private LoggerSettings(string sLogFullFilename)
        {
            m_sLogFullFilename = sLogFullFilename;
            createLoggerSettings();
        }

        public int LogLevel
        {
            get
            {
                if (CurLogger.Level == log4net.Core.Level.Alert)
                    return 1;
                if (CurLogger.Level == log4net.Core.Level.All)
                    return 2;
                if (CurLogger.Level == log4net.Core.Level.Critical)
                    return 3;
                if (CurLogger.Level == log4net.Core.Level.Debug)
                    return 4;
                if (CurLogger.Level == log4net.Core.Level.Emergency)
                    return 5;
                if (CurLogger.Level == log4net.Core.Level.Error)
                    return 6;
                if (CurLogger.Level == log4net.Core.Level.Fatal    )
                    return 7;
                if (CurLogger.Level == log4net.Core.Level.Fine    )
                    return 8;
                if (CurLogger.Level == log4net.Core.Level.Finer    )
                    return 9;
                if (CurLogger.Level == log4net.Core.Level.Finest    )
                    return 10;
                if (CurLogger.Level == log4net.Core.Level.Info    )
                    return 11;
                if (CurLogger.Level == log4net.Core.Level.Log4Net_Debug        )
                    return 12;
                if (CurLogger.Level == log4net.Core.Level.Notice        )
                    return 13;
                if (CurLogger.Level == log4net.Core.Level.Off        )
                    return 14;
                if (CurLogger.Level == log4net.Core.Level.Severe        )
                    return 15;
                if (CurLogger.Level == log4net.Core.Level.Trace            )
                    return 16;
                 if (CurLogger.Level == log4net.Core.Level.Verbose)
                    return 17;
                if (CurLogger.Level == log4net.Core.Level.Warn)
                    return 18;
                return 14;
            }
            set
            {
                switch (value)
                {
                    case 0:
                        this.Level = log4net.Core.Level.Off;
                        break;
                    case 1:
                        this.Level = log4net.Core.Level.Alert;
                        break;
                    case 2:
                        this.Level = log4net.Core.Level.All;
                        break;
                    case 3:
                        this.Level = log4net.Core.Level.Critical;
                        break;
                    case 4:
                        this.Level = log4net.Core.Level.Debug;
                        break;
                    case 5:
                        this.Level = log4net.Core.Level.Emergency;
                        break;
                    case 6:
                        this.Level = log4net.Core.Level.Error;
                        break;
                    case 7:
                        this.Level = log4net.Core.Level.Fatal;
                        break;
                    case 8:
                        this.Level = log4net.Core.Level.Fine;
                        break;
                    case 9:
                        this.Level = log4net.Core.Level.Finer;
                        break;
                    case 10:
                        this.Level = log4net.Core.Level.Finest;
                        break;
                    case 11:
                        this.Level = log4net.Core.Level.Info;
                        break;
                    case 12:
                        this.Level = log4net.Core.Level.Log4Net_Debug;
                        break;
                    case 13:
                        this.Level = log4net.Core.Level.Notice;
                        break;
                    case 14:
                        this.Level = log4net.Core.Level.Off;                        
                        break;
                    case 15:
                        this.Level = log4net.Core.Level.Severe;
                        break;
                    case 16:
                        this.Level = log4net.Core.Level.Trace;
                        break;
                    case 17:
                        this.Level = log4net.Core.Level.Verbose;
                        break;
                    case 18:
                        this.Level = log4net.Core.Level.Warn;
                        break;
                }
            }
        }

        public log4net.Core.Level Level
        {
            get
            {
                return CurLogger.Level;
            }
            set
            {
                CurLogger.Level = value;
            }
        }

        public bool EnableRollingAppender
        {
            get
            {
                foreach (log4net.Appender.AppenderSkeleton appender in CurLogger.Appenders)
                {
                    if (appender is log4net.Appender.RollingFileAppender)
                        return true;
                }
                return false;
            }
            set
            {
                if (value)
                {
                    if (this.EnableRollingAppender == false)
                    {
                        string sLogPath = m_sLogFullFilename;
                        log4net.Appender.RollingFileAppender rollingAppender = CreateRollingFileAppender(sLogPath);
                        CurLogger.AddAppender(rollingAppender);
                        rollingAppender.ActivateOptions();
                    }
                }
                else
                {
                    if (this.EnableRollingAppender)
                    {
                        log4net.Appender.RollingFileAppender rollingAppender = null;
                        foreach (log4net.Appender.IAppender appender in CurLogger.Appenders)
                        {
                            if (appender is log4net.Appender.RollingFileAppender)
                            {
                                rollingAppender = (log4net.Appender.RollingFileAppender)appender;
                                break;
                            }
                        }
                        if (rollingAppender != null)
                            CurLogger.RemoveAppender(rollingAppender);
                    }
                }
            }
        }

        private log4net.Repository.Hierarchy.Logger CurLogger
        {
            get
            {
                log4net.Repository.Hierarchy.Hierarchy hierarchy = (log4net.Repository.Hierarchy.Hierarchy)log4net.LogManager.GetRepository();
                return hierarchy.Root;
            }
        }

        private void createLoggerSettings()
        {
            try
            {
                log4net.Repository.Hierarchy.Hierarchy hierarchy = (log4net.Repository.Hierarchy.Hierarchy)log4net.LogManager.GetRepository();
                hierarchy.Configured = true;
            }
            catch 
            {
            }
        }

        private log4net.Appender.RollingFileAppender CreateRollingFileAppender(string sLogPath)
        {
            log4net.Appender.RollingFileAppender rollingAppender = new log4net.Appender.RollingFileAppender();
            rollingAppender.File = sLogPath;
            rollingAppender.AppendToFile = true;
            rollingAppender.RollingStyle = log4net.Appender.RollingFileAppender.RollingMode.Date;
            rollingAppender.LockingModel = new log4net.Appender.FileAppender.MinimalLock();
            rollingAppender.DatePattern = "_yyyyMMdd\".log\"";
            log4net.Layout.PatternLayout layout = new log4net.Layout.PatternLayout("%date %-5level %logger - %message%newline");
            rollingAppender.Layout = layout;
            return rollingAppender;
        }
    }
}

이 코드를 사용하려면, log를 사용하기 전에 실행되는 위치에 다음과 같은 코드를 넣어주어야 한다.

string sLogPath = "C:\Temp\this.log";
net.knoie.LoggerSettings.CreateInstance(sLogPath);
net.knoie.LoggerSettings.Current.EnableRollingAppender = true;
net.knoie.LoggerSettings.Current.Level = log4net.Core.Level.All;

sLogPath 라는 부분이 있는데, 이 안에 로그파일이 생성되어야 할 위치를 설정해 주면 된다.

이 클래스와 테스트 프로그램은 첨부파일로 같이 첨부한다.
( 첨부된 예제는 Visual Studio 2010 으로 작성된 WinForm Application 이다.)

MyTestProject.zip