특집기사:플러그인 무인 설치

위클립스
이동: 둘러보기, 찾기
Article.png 특집기사 정보
Jeeeyul.jpg
저자 이지율

이문서는 이클립스에 무인으로 업데이트 사이트를 이용하여 플러그인을 인스톨하는 방법을 설명하며, P2의 새로운 매커니즘에 대한 이해를 도울만한 내용을 포함한다.

목차

[편집] 개요

최근 담당하고 있던 기존 제품들을 일제히 3.7로 마이크레이션 하는 작업을 수행하게 되었다. 기존의 빌드 스크립트는 대충 이렇게 돌아갔다.

  1. 피쳐와 플러그인을 빌드한다.
  2. 리포지터리를 퍼블리싱 하고 서명한다. -> 업데이트 서버로 퍼블리싱
  3. 배포 타겟 이클립스의 압축을 풀고, JRE를 포함시킨다.
  4. 해당 이클립스에 제품 피쳐를 설치한다.
  5. 브랜딩 파일을 덧 붙인다. (실행파일, 버그질라 링크, 아이콘 등등)
  6. 인스톨러를 만든다. -> 다운로드 서버로 퍼블리싱.

이클립스 3.7 부터는 모든 프로비져닝 관련 작업을 P2에 완전히 의존하도록 정착 되었기 때문에 전처럼 간단한 방법, 즉 이클립스 폴더에 피쳐와 플러그인을 그대로 덮어쓰는 것이 통하지 않았다. 이렇게 하면, 이클립스 실행시 새로 추가된 피쳐와 플러그인을 전혀 감지하지 못한다.

둘러갈 방법으로는 drop-ins 폴더에 넣는 방법이 있었지만 모양새가 좋아 보이지 않았다.

[편집] 시행착오 1

처음 시도한 방법은, 이런 상황을 위해 준비되어 있는 애플리케이션인 org.eclipse.update.core.standaloneUpdate[1] 애플리케이션을 이용하는 것이었다. 실행했던 코드는 아래와 같다:

eclipse
-application org.eclipse.update.core.standaloneUpdate
-command install
-version x.x.x
-from file://리포지터리위치
실제로는 콘솔이 아니라 앤트 스크립트에서 실행 하였지만 이해하는데 무리가 없을 것이다.

아무런 에러메시지 없이 깔끔하게 실행되었고, 결과는 성공적으로 보였다. 플러그인과 피쳐들은 잘 설치되어 있었고, 피쳐에 정의된 대로, 특정 플러그인들은 압축도 잘 해제 되 있었다.

그러나 막상 실행시켜보니, 추가한 플러그인들은 전부 작동하지 않았고, 플러그인 레지스트리에 포함되어 있지도 않았다.

[편집] Configurator

얼마간의 삽질 후에 찾아낸 용의자는 configuration/org.eclipse.equinox.simpleconfigurator/bundles.info 파일이었다.

이 파일에는 다른 모든 플러그인들의 정보가 다 기재되어 있는데, 내가 추가로 설치한 플러그인들에 대한 정보만 쏙 빠져 있었다.

Oh.jpg
오, 요것봐라?


P2는 굳이 고정된 위치에 플러그인들이 존재할 필요도 없다. 또한 여러 이클립스 설치본들이 플러그인을 공유하여 사용할 수도 있다.

이런 일들이 가능한 이유는 P2의 Configurator라는 중간 계층이 새롭게 추가되었기 때문이다.

더 이상 디스크 레이아웃을 기준으로 플러그인들을 감지 하지 않기 때문에, 설령 물리적으로 플러그인들이 설치되어 있다 하더라도, 프로비져닝 프로필에 포함되지 않은 플러그인들이 작동하지 않았던 것이다.

이래서는 그냥 전 처럼 무식하게 복사하고 왜 안되지? 하는 것과 다를바가 없다. 이는 org.eclipse.update.core.standaloneUpdate 애플리케이션의 버그이거나, 3.7에서 제외되었어야 하는데 미쳐 빠지지 못한 것이 아닌가 여겨진다. 흥, 버그로 등록해 주겠다. (난 착해)

현재 배포되는 이클립스 패키지들은 SimpleConfigurator라고 불리는 단순한 P2 Configurator 의 기본 구현을 탑재하고 있다. 내부 동작구현은 계약 범위 바깥[2]이므로, 자세히 들여다 볼 수 없지만(본다고 해도, 유지가 보증되지 않는 계약이므로), 적어도 configuration/org.eclipse.equinox.simpleconfigurator/bundles.info 파일에 번들들의 정보를 기재하는 것이 확실해 보였다. 그러나 번들 그룹(피쳐)에 대한 정보는 이 파일에 없었고, 그것이 어디에 기재될지 알아내는 것은 어려워 보였다.

알아낸다 한들 스펙의 특정 구현에 불과한 SimpleConfigurator에 맞추어 해킹을 적용하고 싶지는 않았다.

이제 이 문제를 해결하려면 P2가 제공하는 매커니즘을 사용해야 하는 것이 확실해졌다.

[편집] 시행착오 2

P2 관련 문서를 뒤적여 보니, 여전히 부족하기는 하지만, 몇몇 정보들이 업데이트 되어 있었고, 다행히도 P2의 엔진인 Director를 곧바로 실행할 수 있는 애플리케이션[3]이 준비되어있었다. 사용법은 아래와 같이 간단하다:

eclipse
-application org.eclipse.equinox.p2.director
-repository file://리포지터리위치
-installIU 피쳐ID

올레! 이제 끝이구나 했지.

그런데 화면에 이런게 떴다.

Installing MyFeatureID 1.0.0.XXXX.
One or more certificates rejected. Cannot proceed with installation.
Application failed, log file location: ...\configuration\1356499605492.log
Installation failed.
What is this.jpg
이게 뭐지?

우리 제품은 자가 서명되어 있는데, Director 애플리케이션은 신뢰목록에 포함되지 않은 IU를 무조건 리젝트 시키는 것 같았다. 더군다나 오랜 시간동안 Director 애플리케이션의 소스코드를 뜯어본 결과, 자동 신뢰 같은 옵션을 제공하지 않았다.

오. 맘마미야.

[편집] 시행착오 3

우리 제품은 32bit와 64bit JVM을 포함한다.(물론 각기 따로 빌드된다) 조사해본바 Director 애플리케이션은 Java의 기본 인증서 매커니즘에 따라 JVM의 인증목록을 그대로 사용하므로, 이들 JVM의 기본 신뢰 목록에 우리 인증서를 추가[4]해야 하는 상황이 왔다.

참고로 해당 목록을 담은 키스토어 파일은 JRE경로/lib/security/cacerts이다.

우선 신뢰목록에 추가하기 위해 키스토어로 부터 인증파일을 만들었다. 그리고 키툴로 이놈을 신뢰목록에 추가하기로 했다. ANT 코드는 다음과 같다:

  1. <echo>신뢰 인증서 추가중</echo>
  2. <exec executable="${rcp}/${arch}/jre/bin/keytool" 
  3.    input="${basedir}/sign/import.txt"> <!-- Keytool이 신뢰목록에 추가할거냐고 물어보면 y를 눌러주는 파일 -->
  4.    <arg value="-import" />
  5.    <arg value="-alias" />
  6.    <arg value="tomatosystem" />
  7.    <arg value="-keystore" />
  8.    <arg value="${rcp}/${arch}/jre/lib/security/cacerts" />
  9.    <arg value="-storepass" />
  10.    <arg value="changeit" /> 
  11.    <arg value="-file" />
  12.    <arg value="${basedir}/sign/tomatosystem.cer" />
  13. </exec>

이 단계에서 시간을 가장 많이 잡아 먹은 녀석은 바로 10에서, JVM이 신뢰인증서들을 담아두는 기본 키스토어 파일인 cacerts의 기본 패스워드가 changeit이라는 사실을 몰랐다는 점이다.

아무튼 이녀석을 실행하자 앤트는 다음과 같이 기다리던 대답을 뱉어줬다:

[echo] 신뢰 인증서 추가중
[exec] 소유자: CN=기술연구소, OU=전략사업본부, O=토마토시스템, L=강남구, ST=서울특별시, C=KR
[exec] 발급자: CN=기술연구소, OU=전략사업본부, O=토마토시스템, L=강남구, ST=서울특별시, C=KR
[exec] 일련 번호: 4cf3365c
[exec] 유효 기간 시작: XXXXXX 끝: XXXXXX
[exec] 인증 지문:
[exec] 	 MD5:  9B:54:8E:40:F7:D7:CD:14:FC:B9:64:86:13:A6:06:F9
[exec] 	 SHA1: 94:32:01:E1:6D:BF:65:81:ED:60:25:FB:D6:1F:92:A2:2B:47:3B:5D
[exec] 	 서명 알고리즘 이름: SHA1withDSA
[exec] 	 버전: 3
[exec] 이 인증서를 신뢰하십니까? [아니오]:  인증이 keystore에 추가되었습니다.

이제 P2의 Director를 이용하여 설치하는데 문제가 없을 것 같았고, 다시 시도해 보았다:

[echo] eXRIA 스튜디오 설치중...
[exec] Installing org.exria.studio.editor 2.0.0.201212261125.
[exec] Operation completed in 12946 ms.

올레! -ㅂ-! 됐다!

[편집] 결론

최종적으로 빌드 스크립트는 다음과 같은 모양이 되었다:

<echo>타겟의 Eclipse 압축 해제 중.</echo>
<unzip dest="${rcp}/${arch}" src="${rcpBase}/${arch}/eclipse.zip" />
 
<echo>JRE 삽입 중</echo>
<unzip dest="${rcp}/${arch}/jre" src="${rcpBase}/${arch}/jre.zip" />
 
<echo>신뢰 인증서 추가중</echo>
<exec executable="${rcp}/${arch}/jre/bin/keytool" input="${basedir}/sign/import.txt">
   <arg value="-import" />
   <arg value="-alias" />
   <arg value="tomatosystem" />
   <arg value="-keystore" />
   <arg value="${rcp}/${arch}/jre/lib/security/cacerts" />
   <arg value="-storepass" />
   <arg value="changeit" />
   <arg value="-file" />
   <arg value="${basedir}/sign/tomatosystem.cer" />
</exec>
 
<echo>eXRIA 스튜디오 설치중...</echo>
<exec executable="${rcp}/${arch}/eclipse.exe">
   <arg value="-application" />
   <arg value="org.eclipse.equinox.p2.director" />
   <arg value="-repository" />
   <arg value="file://${repository}" />
   <arg value="-installIU" />
   <arg value="org.exria.studio.editor" />
</exec>
<!-- 이하 생략 -->

P2의 디랙터가 독립적으로 아주 잘 작동한다는 것은 반가운 소식이다. 수많은 이클립스들이 설치되어 있는 개발 환경에서, 잘 만든 스크립트를 이용하여 무인 환경 셋업도 손쉽게 가능할 듯 보인다.

[편집] 참조

  1. http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fupdate_standalone.html
  2. 계약 범위 바깥: 계약은 절대적이다, 동의 하지 않으면 특집기사:이클립스 API 사용법을 읽어보라
  3. http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_director.html
  4. http://docs.oracle.com/javase/tutorial/security/toolsign/rstep2.html

이 기사에 대한 의견은 토론 페이지를 통해 나눌 수 있습니다.

개인 도구
이름공간
변수
행위
포탈
탐색
도움
도구모음