Sun Developer Network 공식 블로그

branded 존은 솔라리스 운영체제의 다른 버전을 실행할 수 있는 존입니다. 솔라리스8, 솔라리스9 branded 존의 소개로 인해서 기존의 설치환경을 존으로 옮기는 것이 매우 쉬워졌습니다. 단순히 설치본의 플래시 어카이브를 생성하고 branded 존을 생성한다음 플래시 어카이브를 이용해서 존에 OS 를 설치 하면 됩니다.

그러나 솔라리스10 존을 설치하기 위해 사용되는 네이티브 brand 에서는 이러한 기능을 지원하지 않습니다. 이 기능은 만약 현존하는 솔라리스10 설치본을 다른 하드웨어로 옮길때 매우 유용할 것입니다. 존안에 새로운 솔라리스10 배포판 사용을 원할때도 유용할 수 있습니다.

이 글은 솔라리스10 존을 플래시 어카이브를 통해서 설치하기 위해 솔라리스10 brand 를 생성하는 방법을 설명하고 있으며 다음과 같은 주제들을 다루고 있습니다:

• branded 존 파일
• 솔라리스10 brand 빌드하기
• branded 존 생성 및 설치하기
• 존의 오류 서비스들을 복구하기
• 오류 서비스 해결책 자동화 하기

branded 존 파일

현재 두가지의 brand 가 존재 합니다: 솔라리스8 brand 와 솔라리스9 brand.

솔라리스9 브랜드는 솔라리스10 brand 를 생성하기 위해 사용되는 템플릿으로 이용되는 네이티브 brand 와 합쳐져 있습니다. 네이티브 brand 에 대해 먼저 살펴 봅시다.

네이티브 brand 의 위치는 다음과 같습니다:

/usr/lib/brand/native

이 데렉토리는 3가지 파일을 가지고 있습니다:

• config.xml 은 설치, 검사, 부팅, 존의 권한을 설정하기 위한 모든 정보를 포함하고 있습니다
• platform.xml 은 디바이스와 존의 마운트를 위한 정보를 포함하고 있습니다
• postclone 은 존의 클로닝 이후에 수행되어야할 작업들의 정보를 포함하고 있습니다

솔라리스9 brand 는 조금 더 복잡합니다. 위치는 다음과 같습니다:

/usr/lib/brand/Solaris9

이 디렉토리는 네이티브 존의 디렉토리와 동일한 파일들을 포함하고 있습니다. 그러나 다음의 파일들 또한 특수한 용도를 위해 포함하고 있습니다:

• s9_install. 이 스크립트는 시스템을 어떻게 설치할지와 s9_p2v 파일의 위치를 지정하고 있습니다.
• s9_p2v. 이 스크립트는 정보의 후처리방법을 담고 있습니다. 가장 중요한 기능은 수정될 파일들의 위치와 s9_system 파일의 위치 입니다.
• s9_servicetag. 이 스크립트는 servicetag 를 존에 추가 합니다. 이 파일은 s9_install 파일에 의해 참조 됩니다.
• s9_support. 이 바이너리는 zonecfg verify 서브커맨드에 의해 사용되며 존의 설정을 검사 합니다.
• s9_system. 이 스크립트는 새로운 존의 /etc/default/system 파일을 수정합니다.

솔라리스9 brand 는 또한 다음의 서브디렉토리들을 포함하고 있습니다:

• files/patches. 이 디렉토리는 order 파일을 포함하고 있는 데 이 파일은 어떠한 패치들이 설치되어야 하는지에 대한 순서를 설명합니다. 실제 패치들은 files/patches 에 또한 존재 합니다.
• mods. 이 디렉토리는 설치후 수정작업들을 포함하고 있습니다. s9_p2v 스크립트는 이 디렉토리에 나타난 순서대로 하나씩하나씩 수정을 가합니다.

파일에 특수한 용도가 있는 것인지는 s9_install 파일을 살펴 봄으로써 알아볼 수 있습니다. 이 파일은 config.xml, 에 의해 정의도고 존 설치시에 사용 됩니다. 모든 파일들은 s9_install 에서 참조된 모든 파일들이 포함되고 또한 참조 파일들에 의해서 참조되는 모든 파일들 또한 포함됩니다. 참조 트리는 그림 1 과 같이 적용 됩니다.

또한 s9_support 파일도 포함 됩니다. 왜냐하면 이것은 존의 설정 검사를 위해 사용되기 때문입니다. 만약 솔라리스10 branded 존을 pkg-inherit-dir 변수를 이용해 설정하려고 한다면 에러를 돌려 줍니다. 이 파일은 config.xml 에서 참조 됩니다 (솔라리스10 brand 빌드하기 섹션을 참조하시기 바랍니다).

솔라리스10 brand 빌드하기

이제 특수한 파일들과 디렉토리들이 식별되었고, 여러분은 솔라리스10 brand 를 빌드하실 수 있습니다.

1. 디렉토리 구조 생성하기:

/usr/lib/brand/solaris10
/usr/lib/brand/solaris10/mods
/usr/lib/brand/solaris10/files
/usr/lib/brand/solaris10/files/patches

2. 표 1에서 나온 대로 네이티브 brand 와 솔라리스9 brand 에서 파일들을 복사하기 (경로들은 /usr/lib/brand/ 로 부터 상대적임)

3. 다음 파일들의 정보를 수정하기:

a. config.xml 에서:

• brand name=native 을 brand name=solaris10 으로 교체
• <install>/usr/lib/lu/lucreatezone -z %z</install> 을 <install>/usr/lib/brand/solaris10/s10_install %z %R %*</install> 로 교체
• <installopts></installopts> 을 <installopts>a:d:DhpsuvV</installopts> 로 교체.
• <verify_cfg></verify_cfg> 을 <verify_cfg>/usr/lib/brand/solaris10/s10_support verify</verify_cfg> 로 교체.

b. platform.xml 에서 아래 라인을 추가 함으로써 /usr 파일 시스템의 루프백 마운트를 위한 (이후의 수정사항을 적용하기 위해 필요함) 추가 항목을 생성 합니다.:

<global_mount special="/usr" directory="/.SUNWnative/usr" \
type="lofs" opt="ro,nodevices" />

c. s10_install, s10_servicetag 그리고 s10_system 파일에 존재하는 모든 Solaris9 과 s9 을 각각 Solaris10 과 s10 으로 변경합니다.

d. s10_p2v 에서:

• 모든 Solaris9 과 s9 을 각각 Solaris10 과 s10 으로 변경합니다.
• s9_preload.so.1 라이브러리와 관련된 항목들을 커멘트 처리 합니다. 왜냐하면 이 라이브러리는 솔라리스10 에 필요하지 않기 때문입니다.

branded 존 생성 및 설치하기

이제 brand 가 생성되었고 솔라리스10 branded 존 설정이 가능합니다:

zonecfg -z 10_zone01
	create
	set autoboot=true
	set zonepath=/export/zones/solaris10/zone01
	set brand=solaris10
	add net
		set physical=hme0
		set address=10.0.0.1/24
	end
	remove inherit-pkg-dir
	verify
	commit

설정된 존은 이제 플래시 어카이브(/tmp/solaris10.flar) 를 이용해서 설치 가능합니다:

zoneadm -z 10_zone01 install -p -a /tmp/solaris10.flar

15분 정도의 작업 후에 존은 사용될 준비가 되었습니다.

존의 오류 서비스들을 복구하기

존이 처음 부팅될때는 유지보수 모드(maintenance mode) 로 부팅될 것이고 몇몇 서비스들은 정상적으로 시작되지 않을 것입니다. 이것은 몇몇 서비스들이 존에서 실행이 불가능함으로써 발생되는 현상 입니다. 이러한 서비스들을 제거하고 머신을 제거함으로서 의존성을 해결할 수 있습니다.

이 방법은 물론 빠르지만 약간 지저분한 방법입니다. 진짜로 해야 할 일은 p2v 수정을 작성함으로써 인스톨 후 과정에서 서비스들과 의존성들을 제거하는 것입니다.

이 글에서 사용된 솔라리스10 플래시 어카이브는 설치에 필요한 최소의 어카이브 입니다 (SUNWCreq 클러스터). 대형 클러스터 환경에서는 서비스들이 완벽하지 않을 것입니다. 어쨌든 이러한 것을 다루는 방법은 동일 합니다.

존에서 실행되지 않는 서비스들의 목록은 플래시 어카이브를 통해 설치된 존에서 사용가능한 서비스들의 목록과 네이티브 존에서 실행되는 서비스들의 목록을 비교하여 만들어 졌습니다. 다음의 서비스들은 존 내부에서 실행되지 않습니다. 왜냐하면 플래시로 설치된 존에서는 존재하지만 네이티브 존에서는 존재하지 않기 때문입니다:

• svc:/network/nfs/server
• svc:/system/dumpadm
• svc:/system/scheduler
• svc:/system/sysevent
• svc:/system/picl
• svc:/system/fmd
• svc:/system/device/fc-fabric

각각의 서비스들을 위해서 의존성들이 해결되어야 합니다. 다음의 예는 sysevent 서비스의 의존성을 다룹니다.

svcs -D 를 이용해서 어떠한 서비스들이 sysevent 서비스에 의존하고 있는지 확인합니다:

bash-3.00# svcs -D sysevent
STATE      STIME    FMRI
online     Mar_11   svc:/system/device/fc-fabric:default
online     Mar_11   svc:/milestone/single-user:default
online     Mar_11   svc:/system/fmd:default

각각의 의존 서비스들은 속성들을 확인해서 서비스 디스크립터에서 의존성을 제거할 수 있는지 확인 합니다:

bash-3.00# svccfg -s fc-fabric listprop
sysevent              dependency
sysevent/entities     fmri     svc:/system/sysevent
sysevent/grouping     astring  require_all
sysevent/restart_on   astring  none
sysevent/type         astring  service
---output truncated---

그림 2의 의존성 트리는 현재의 상황에서 적용 가능합니다.

이제 우리들은 의존성들을 지우고 서비스들을 비활성화해야 합니다, 그리고 낮은 수준에서 높은 수준 순으로 작업해야 합니다. 그림 3의 흐름도는 과정을 보여주고 있습니다.

이 흐름도와 sysevent 서비스의 의존성 트리를 이용해서 여러분은 서비스들을 트리의 낮은 수준의 서비스 부터 시작해서 수정 할 수 있고 이런 경우 milestone/devices 가 가장 낮은 수준의 서비스 입니다.

다음의 목록에서 번호들은 흐름도에서 물어진 질문 들입니다. 의존성을 제거하기 위해서 svccfg -s <FMRI> delpg <property_group> 커맨드를 이용하는데 여기서 <FMRI> 는 오류 관리 리소스 인식자(fault management resource identifier

• svc:/milestone/devices: 1: yes; 2: yes; 의존성을 제거 (devices property group).
• svc:/system/device/fc-fabric: 1: no; 서비스를 제거.
• svc:/milestone/single-user: 1: yes; 2: yes; 의존성을 제거 (syseventd_single-user property group).
• svc:/system/fmd: 1: no; 서비스를 제거.
• svc:/system/sysevent: 1: no; 서비스를 제거. 이제 이것은 올바른 작업입니다. 왜냐하면 모든 의존성들이 제거 되었기 때문입니다. 또한 이것이 하위 레벨부터 상위레벨 순으로 작업해야 하는 이유 이기도 합니다.

존에서 실행되지 않는 서비스들에 차례대로 위와 같은 흐름도를 적용 합니다. 몇몇 중첩된 사항들이 존재하기도 합니다. 예를 들어 fc-fabric 서비스는 sysevent을 처음으로 수정했다면 이미 삭제되었을 것입니다. 삭제된 모든 서비스들과 서비스의 속성들을 반드시 로그로 남기시기 바랍니다.

오류 서비스 해결책 자동화 하기

마지막으로 해야할 일은 존의 오류 서비스들을 복구하기 에서 기술된 해결책을 자동화 하는 것입니다. 이것을 위해서 S40_fix_services 스크립트를 만들고 이것을 솔라리스10 brand 의 mods 디렉토리에 넣습니다. 기본적으로 여러분은 위의 섹션에서 만들어 놓은 기록들을 이용해서 스크립트를 생성할 수 있습니다.

이 스크립트는 최소한 다음의 두가지 기능을 가지고 있어야 합니다:

• 지정된 서비스의 지정된 속성 값 삭제
• 서비스 삭제

대안으로 여러분은 삭제 대신에 서비스를 비활성화 할 수도 있습니다. 물론 삭제가 선호되기는 하는데 왜냐하면 어쨌든 서비스들은 실행되지 못할 것이기 때문입니다.

스크립트가 완성된 다음에는 존의 재설치 후에 시스템이 정상적으로 부팅 될 것입니다.


이 글의 영문 원본은
Installing Solaris 10 Branded Zones From a Flash Archive
에서 보실 수 있습니다.