이 문서는 패지 종류에 대한 개요를 제공합니다. 또한 패치들관의 기본적인 연관성에 대해서도 설명합니다.
패치의 정의
패치는 운영체제 혹은 기타 지원되는 소프트웨어들 내의 알려진 문제 혹은 잠재적인 문제에 대한 픽스들의 집합입니다. 패치는 또한 새로운 기능이나 특정 소프트웨어 배포판의 향상된 기능을 제공하기도 합니다. 패치는 기존의 파일과 디렉토리들을 교체 하거나 수정하는 파일 및 디렉토리들로 구성되어 있습니다.
대부분의 솔라리스 패치들은 작은 SVR4 패키지들의 집합으로써 제공 됩니다. 패치는 하나 혹은 그 이상의 작은 패키지들을 포함할 수 있습니다. 이러한 작은 패키지들은 오직 배포판내에서 솔라리스가 처음으로 제공했던 패키지 내에서 변경된 오브젝트들 만을 포함합니다. 이러한 작은 패키지들에 의해 코드가 변경될때 전체 패키지를 완전히 재배포할 필요 없이 작은 패치들만을 배포하는 것이 가능합니다. 작은 패키지들은 사용자 환경에 대한 변화를 최소화 해 줍니다.
각 패치들은 패치 인식 번호 (patch ID) 에 의해 구분됩니다. 패치 ID 는 6자리 숫자의 구분자와 2자리 숫자의 버전 넘버로 이루어진 xxxxxx-yy 의 형태를 갖습니다.
패치들은 누적됩니다. 최후의 버전은 이전 버전에서 배포되었던 모든 기능들을 포함하고 있습니다. 예를 들어 패치 123456-02 는 123456-01 의 모든 기능들과 더불어 버전 2 에서 새롭게 추가된 버그 픽스 혹은 기능들을 포함하고 있습니다. 변경 사항은 패치 README 파일에 포함되어 있습니다.
패치 종류에 대한 개요
이 섹션은 패치의 종류들에 대해 설명합니다.
|
표 1 패치의 종류 |
|
패치의 특징들
다음 섹션에서는 패치의 특성들에 대한 기본적인 정보를 제공합니다.
README 파일 내의 키워드
키워드가 제공됨으로써 사용자들이 그들의 환경에는 어떠한 것들이 적용이 가능한지를 인식할 수 있도록 도와 줍니다. 가장 중요한 키워드는 "Security" 입니다. Security 는 패치가 보안에 대한 픽스를 포함하고 있음을 의미하고 그러므로 매우 중요하게 고려되어야 합니다. 다른 키워드는 영향을 받는 서브 시스템, 하드웨어 플랫폼, 혹은 유저 커맨드들을 포함하고 있을 것입니다.
패치 메타데이타
패치들은 패치의 속성을 설명하는 메타데이타와 연관되어 있습니다. 메타데이타는 “설치 후 재부팅” 혹은 “싱글-유저 모드 설치 필요” 같은 특별한 취급이 필요한 요구사항들을 포함하고 있습니다. 이러한 속성들은 README 파일에 텍스트 형태로 번역되어 있고 반드시 읽어야 합니다.
솔라리스 패치 유틸리티는 또한 pkginfo 와 pkgmap 파일에 포함된 메타데이타들을 활용 합니다.
논-글로벌 존을 위한 패치 메타데이타
패치에는 특정 솔라리스 존에 대한 메타데이타를 포함하고 있어서 존 환경에서의 올바른 패치를 가능하도록 합니다. 자세한 정보는 다음의 참고자료에서 찾으실 수 있습니다:
patchadd(1M) 커맨드의-G옵션- Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones
패치 의존성 (상호연관성)
패치에서 제겅되는 기능, 즉 버그 픽스 혹은 새로운 기능은 다른 패치에서 제공되는 기능들과 서로 상호연관성이 있을 수 있습니다.
이러한 상호연관성은 패키지 내의 pkginfo 파일 내에 3가지 필드들에 의해 결정 됩니다:
SUNW_REQUIRES필드는 패치 의존성을 구분 합니다. 이러한 필수 요구 패치들은 반드시 해당 패치를 설치하기 전에 설치되어 있어야 합니다.SUNW_OBSOLETES필드는 패치내에 누적된 내용을 구분 합니다. 이 새로운 패치는 기존의 패치들을 쓸모 없게 만듭니다.SUNW_INCOMPAT필드는 이 패치와 호환되지 않는 패치들을 구분 합니다. 그러므로 동일한 시스템에는 설치될 수 없습니다.
이 필드들은 솔라리스 patchadd 와 patchrm 커맨드에 의해 사용되어 져서 자동으로 패치하려는 타겟 시스템의 일관성을 보장합니다. 해당 필드들은 패치의 README 파일에 사람이 읽을 수 있는 형태로 변환되어져 있습니다.
패치 의존성을 위한 SUNW_REQUIRES 필드
SUNW_REQUIRES 는 패치 의존성을 구분합니다. 패치에서 제공되는 기능은 다른 패치에 의해 제공되는 변경사항 혹은 기능에 의존성을 가질 수 있습니다. 그러므로 하나의 패치는 올바르게 동작하기 위해 하나 혹은 그이상의 다른 패치들을 요구할 수 있습니다. 만약 패치가 하나 혹은 그 이상의 패치를 의존하고 있다면 패치는 패키지 내의 pkginfo 파일 내에 SUNW_REQUIRES 필드에 요구되는 패치들을 지정합니다. 이 정보는 README 파일에 반영이 됩니다. 이러한 필수 요구 패치들은 반드시 해당 패치의 설치 전에 설치가 되어져 있어야 합니다.
의존성 요구사항들은 오직 한방향으로만 동작합니다. 만약 패치 A 가 패치 B 를 요구한다면 패치 B 는 패치 A 를 요구할 수 없습니다. 그러므로 패치들은 집약적입니다. 만약 패치 A-01 이 패치 B-01 을 필요로 한다면 패치 B 의 -01 보다 큰 패치들은 또한 요구사항을 만족합니다.
만약 다른 종류의 의존성들이 존재한다면 그것들은 패치 README 파일에 기술되어 있고 다음과 같은 사항들을 포함할 수 있습니다:
- 조건 의존성은 오직 특정 조건에서만 발생하는 하드 코드된 의존성을 가르킵니다. 예를 들어 만약 CDE 1.3 이 타겟 시스템에 설치되었을때 같은 경우 입니다.
- 소프트 의존성은 특정 버그 픽스 혹은 기능을 완벽히 제공하기 위해 필요로 하는 다른 패치들을 가르 킵니다. 그러나 다른 패치들 없이도 시스템은 여전히 안정적인 상태입니다.
쓸모 없어진 패치 및 누적을 위한 SUNW_OBSOLETES 필드
SUNW_OBSOLETES 필드는 쓸모 없어진 패치 및 누적 패치를 가르킵니다. 종종 버그 픽스 혹은 새로운 기능은 서로 밀접하게 엮인 두개 혹은 그 이상의 패치들을 만들어 냅니다. 예를 들어 상호간에, 하드-코드 된 의존성이 두 패치 간에 존재할 수 있습니다. 이러한 경우 두개 혹은 그이상의 패치를 하나의 패치로 엮는 작업이 필요한데 그 때문에 다른 패치를 렌더링하거나 쓸모 없게 만들어 버립니다. 다른 패치들의 기능들이 누적되어서 들어가 있는 패치 내에는 해당 패치들의 ID 들 혹은 그것이 쓸모 없게 만들어 버린 패치들을 가르키고 있습니다. 이러한 정보는 패치의 소규모 패키지들 내의 pkginfo 파일에 SUNW_OBSOLETES 필드에 포함되어 있습니다.
패치 누적은 오직 한방향으로만 동작합니다. 그것은 만약 패치 A 가 패치 B 를 포함하고 있다면 패치 A 는 이제 패치 B 의 모든 기능을 포함하고 있는 것을 의미 합니다. 이제 패치 B 는 쓸모가 없어 졌습니다. 더이상의 패치 B 는 나오지 않을 것입니다.
패치의 누적때문에 패치의 이후 버전은 “암묵적으로” 동일한 패치의 이전 버전을 쓸모 없게 만들어 버립니다. 암묵적으로 쓸모 없어진 패치들은 SUNW_OBSOLETES 필드에 플래깅 되지 않습니다. 예를 들어 패치 A-버전 xx 는 명시적으로 패치 A-버전 x-1 을 pkginfo 파일 내의 SUNW_OBSOLETES 항목에 기록할 필요가 없습니다.
참고 - 솔라리스10과 솔라리스 10 배포판(2007년 8월 이후 버전) 에서 아무런 변경 사항도 포함하지 않은 패치들이 배포 되었을 수도 있습니다. 이러한 패치는 몇달 전에 배포되었던 다른 패치들을 쓸모 없는 것으로 가르킬 수 있습니다. 이것은 솔라리스 업데이트 패치를 만들기 위한 과정의 일환으로 생긴 결과 입니다. 쓸모 없어진 패치들이 설치되었고 새로운 패치가 어떠한 변경사항도 가지고 있지 않다면 반드시 이 새로운 패치를 인스톨할 필요가 없습니다.
예를 들어 솔라리스10 timezones 패치 122032-05 는 125378-02 에 의해 쓸모 없어 졌습니다. 그러나 이미 122032-05 가 설치되어 있다면 125378-02 을 설치할 필요가 없습니다. 왜냐하면 패치 125378-02 는 어떠한 변경도 제공하지 않기 때문입ㄴ디ㅏ.
비호환성을 위한 SUNW_INCOMPAT 필드
이따금 두개 혹은 그이상의 패치가 서로 호환이 안될 수 있습니다. 이러한 일은 포인트 패치 혹은 IDR 에서 자주 벌어 벌어지고 정규 패치에서는 거의 일어나지 않습니다. 이러한 비호환성은 SUNW_INCOMPAT 필드에 지정됩니다.
패치 비호환성은 양방향 입니다. 만약 패치 A 혹은 패치 B 가 다른 패치에 대한 비호환성을 지정하고 있다면 타겟 시스템에는 오직 하나의 패치만 설치가 가능합니다. 예를들어 패치 A 는 이미 타겟 시스템에 설치되어 있고 패치 B 가 이 패치에 비호환적이라면 패치 설치 유틸리티 patchadd 는 패치 B 가 설치 되는 것을 허락하지 않을 것입니다. 만약 패치 B 가 반드시 설치되어야 한다면 패치 A 는 반드시 제거되어야 합니다.
패치 혹은 비호환적인 쌍이 반드시 비호환성을 정의해야할 필요는 없습니다. 일반적으로 포인트 패치 혹은 IDR 은 비호환성을 정의하고 있고 그러므로 이러한 패치들은 비표준 코드 브랜치에서 유래 합니다.
패치에 대한 상세 정보
|
표 2 패치 참고자료 |
|
저자 : Lynne Thompson
이 글의 영문 원본은
http://www.sun.com/bigadmin
에서 보실 수 있습니다.
"관리자코너" 카테고리의 다른 글
- 메타 데이터베이스 삭제 사고 시 솔라리스 OS의 시스템 복구 (댓글 0개 / 트랙백 0개) 2008/07/10
- 멀티스레드 시스템의 리소스를 최대한 사용하기 위한 기본 예약 클래스 설정 (댓글 0개 / 트랙백 0개) 2008/07/15
- DTrace 를 이용하여 Defunct 프로세스 문제 해결하기 (댓글 0개 / 트랙백 0개) 2008/07/28
- 솔라리스 볼륨 메니저를 이용하여 솔라리스9, 10 에서 루트를 미러링 하는 방법 (댓글 1개 / 트랙백 0개) 2008/09/20
- UFS Dump 의 안전한 관리 방법 (댓글 14개 / 트랙백 1개) 2007/08/20
- 솔라리스9 혹은 그 이상 버전을 운용하는 시스템상의 하드 디스크로 부터 WAN 부트이용하기 (댓글 0개 / 트랙백 0개) 2007/12/14
- rsync 와 sudo 를 이용한 원격 업데이트 (댓글 0개 / 트랙백 0개) 2008/03/11
- 윈도우 혹은 리눅스에서 솔라리스 파티션에 접근하기 (댓글 0개 / 트랙백 0개) 2008/05/19
- 솔라리스 라이브 업그레이드를 이용하여 논-글로벌 존의 솔라리스10을 업그레이드 하는 방법 (댓글 0개 / 트랙백 0개) 2008/01/16
- 썬 디바이스 검출 툴 - 버젼 1.0 (댓글 3개 / 트랙백 0개) 2007/01/23
댓글을 달아 주세요