이 문서는 패지 종류에 대한 개요를 제공합니다. 또한 패치들관의 기본적인 연관성에 대해서도 설명합니다.


패치의 정의

패치는 운영체제 혹은 기타 지원되는 소프트웨어들 내의 알려진 문제 혹은 잠재적인 문제에 대한 픽스들의 집합입니다. 패치는 또한 새로운 기능이나 특정 소프트웨어 배포판의 향상된 기능을 제공하기도 합니다. 패치는 기존의 파일과 디렉토리들을 교체 하거나 수정하는 파일 및 디렉토리들로 구성되어 있습니다.

대부분의 솔라리스 패치들은 작은 SVR4 패키지들의 집합으로써 제공 됩니다. 패치는 하나 혹은 그 이상의 작은 패키지들을 포함할 수 있습니다. 이러한 작은 패키지들은 오직 배포판내에서 솔라리스가 처음으로 제공했던 패키지 내에서 변경된 오브젝트들 만을 포함합니다. 이러한 작은 패키지들에 의해 코드가 변경될때 전체 패키지를 완전히 재배포할 필요 없이 작은 패치들만을 배포하는 것이 가능합니다. 작은 패키지들은 사용자 환경에 대한 변화를 최소화 해 줍니다.

각 패치들은 패치 인식 번호 (patch ID) 에 의해 구분됩니다. 패치 ID 는 6자리 숫자의 구분자와 2자리 숫자의 버전 넘버로 이루어진 xxxxxx-yy 의 형태를 갖습니다.

패치들은 누적됩니다. 최후의 버전은 이전 버전에서 배포되었던 모든 기능들을 포함하고 있습니다. 예를 들어 패치 123456-02 는 123456-01 의 모든 기능들과 더불어 버전 2 에서 새롭게 추가된 버그 픽스 혹은 기능들을 포함하고 있습니다. 변경 사항은 패치 README 파일에 포함되어 있습니다.


패치 종류에 대한 개요

이 섹션은 패치의 종류들에 대해 설명합니다.

표 1 패치의 종류

패치 타입

설명

Kernel 패치 (이전에는 Kernel Update [KU] 패치)

일반적으로 사용가능한 표준 패치. 이 패치는 매우 중요합니다. 왜냐하면 변화의 범위가 시스템에 영향을 미치기 때문입니다. 커널 패치는 솔라리스 커널과 관련 코어 솔라리스 기능들을 변경합니다. 새로운 커널 버전을 활성화하기 위해서는 재부팅이 요구 됩니다.

Temporary 패치 (T-패치)

배포를 위해 빌드 되고 제출되었지만 전체 테스트 및 검증 과정을 거치지 않은 패치 입니다.

공식적으로 배포되기 이전에 솔라리스 패치들은 구조적으로 검증되고 시스템 테스트 프로세스 과정을 거칩니다. 테스트는 패치들이 “T-패치” 상태일때 이루어 집니다. 성공적으로 테스트 과정이 끝나면 공식적으로 배포 됩니다. 썬의 패치 테스트 과정에 대한 개요는 patch test 를 읽어 보시기 바랍니다.

T-패치는 해당 문제를 제기한 고객이 패치가 문제점을 픽스해 주는지 검사 할 수 있도록 사용이 가능할 것입니다. 이러한 패치의 종류는 패치 ID 에서 “T” 로 시작함으로써 구분됩니다. 예를 들어 T108528-14 등이 바로 그런 경우 입니다. 단어 “(Preliminary Patch - Not Yet Released)” 가 패치 README 파일의 제일 앞줄에 나타납니다. 패치가 테스트 되고 검증된 다음에 T-패치 지시자는 제거 되고 패치는 배포 됩니다.

참고 - 만약 T-패치가 설치되었고 패치가 동일한 버전으로 배포 되었다면 T-패치를 제거할 필요는 없습니다. 배포된 버젼과 T-패치 는 README 파일을 제외하고 동일할 것입니다.

Security T-패치;

SunSolve 사이트의 보안 T-패치 섹션은 보안 이슈들을 해결하는 초기 단계의 패치들에 대한 접근을 제공합니다. Security T-Patch download section 페이지를 참고하시기 바랍니다.

이러한 패치들은 여전희 T-패치 단계에 있고 이것은 아직 검증 작업및 테스팅 과정이 완료되지 않았음을 의미 합니다. 보안 T-패치를 설치 하는 것은 사용자들의 자유이고 또한 리스크 입니다. 보안 T-패치들에 의해 해결된 이슈들에 대한 정보와 가능한 회피방법(workaround)들은 무료 보안 썬 경보 데이타 집합(Free Security Sun Alert data collection) 을 통해 제공 됩니다. Sun Security Coordination Team 페이지를 참고하시기 바랍니다.

Rejuvenated 패치

너무 크고 복잡하게 변해버린 패치는 “rejuvenation.” 절차를 따릅니다. rejuvenation 프로세스는 복잡한 새로운 기능들을 상대적으로 안전하게 점차적으로 설치하는 패치를 제공합니다. 패치가 rejuvenated 패치로 변경되면 더이상 새로운 버전의 패치는 생성되지 않습니다. 그 대신 rejuvenated 패치는 새로운 패치 ID 의 시리즈로 제공 됩니다. 이러한 새로운 패치들은 rejuvenated 패치를 요구하고 의존 합니다. 만약 새로운 패치중의 하나가 시간이 지남에 따라 복잡해 지면 이 패치는 rejuvenated 패치가 될 수 있습니다. 예를 들어 커널 패치는 필요에 의해 rejuvenate 됩니다.

이러한 과정의 장점은 비록 고객이 복잡한 패치를 한번에 설치해야 하더라도 이후의 패치는 훨씬 간단하게 설치할 수 있습니다.

좀 더 자세한 정보는 SunSolve Patch Rejuvenation 을 참고하시기 바랍니다.

point 패치

커스텀 패치. 이 패치는 오직 해당 고객에게만 발생하는 특정 문제에 대한 응답으로써 제공됩니다. point 패치는 해당되는 고객만 사용해야 합니다. 이러한 패치들은 일반적으로 오직 한명의 고객을 위해서만 만들어지는데 왜냐하면 대부분의 고객들은 패치가 제공하는 "fix" 가 fix 가 해결하는 문제보다 더 시스템을 악화시킬 수 있다고 생각하기 때문입니다. 이러한 패치들은 솔라리스 소스 코드의 한 줄기로써 생성되며 메인 소스 베이스와 합쳐지지 않습니다.

포인트 패치에 대한 접근은 제한되어 있고 오직 썬 서포트 직원과의 상담 이후에 설치되어야 합니다.

restricted 패치 (R-patch)

흔하지 않은 패치로 특수한 목적을 가지고 있습니다. R-패치는 패키지 수정에 lock 을 걸어 줍니다. 이 lock 은 다른 패치들에 의한 패키지 변경을 막아 줍니다.

R-패치는 point 패치와 비슷한 환경에서 사용됩니다. point 패치 처럼 R-패치는 오직 패치가 전달되는 고객들만 사용해야 합니다. 이러한 패치들은 솔라리스 소스 코드 베이스의 한 가지로 생성되고 메인 소스 베이스로 합쳐지지 않습니다.

"공식" 표준 패치가 적용되기전에 R-패치는 반드시 수동으로 제거되어야 합니다.

Interim Diagnostic Relief (IDR)

IDR 은 고객의 문제를 진단하거나 이슈에 대한 최소의 그리고 임시의 자료들을 제공하는데 도움을 주는 소프트 웨어 입니다. IDR 은 R-패치 와 비슷한 패치 포맷으로 제공 됩니다. 그러나 IDR 이 이슈에 대한 최종 픽스를 제공하지 않기 때문에 IDR 은 실제 패치의 대체제가 아닙니다. 공식적인 패치 혹은 패치들이 나오는대로 IDR 은 대체 되어져야 합니다.

좀더 자세한 정보는 Interim Relief/Diagnostics 을 참고하시기 바랍니다.

Interim Security Relief (ISR)

널리 알려진 보안 이유를 픽스하는 패치 입니다. 이 패치는 IDR 의 한 종류 입니다. ISR 은 널리 알려진 보안 취약성에 대한 초기 단계의 픽스를 제공하기 위한 것입니다. ISR 은 완전히 리뷰되지 않았고 검증되지 않았으며 테스팅 프로세스도 거치지 않았습니다. ISR 의 설치는 사용자 본인의 판단이며 책임도 본인에게 있습니다. ISR 은 SunSolve 의 Security T-Patch download section 에서 받으실 수 있습니다. ISR 에 의해 해결되는 이슈들에 대한 정보와 가능한 회피책은 Sun Alert 데이타 컬렉션에서 얻으실 수 있습니다. Sun Security Coordination Team 페이지를 참고하시기 바랍니다.

Nonstandard 패치

patchadd 커맨드를 통해 설치 될 수 없는 패치 입니다. nonstandard 패치는 패키지 포맷으로 배포되지 않습니다. 이 패치는 반드시 README 파일에 기술된 “Special Install Instructions” 에 의해서 설치해야 합니다. nonstandard 패치는 일반적으로 펌웨어 혹은 어플리케이션 소프트웨어의 픽스를 배포합니다.

Withdrawn 패치

만약 패치가 심각한 이슈를 유발하는 것으로 판단되면 패치는 SunSolve 에서 제거 됩니다.

  • 해당 패치는 더이상 다운로드가 불가능합니다.
  • README 는 SunSolve 에 남게 됩니다. README 는 해당 패치가 withdrawn 되었고 문제에 대한 간략한 설명과 왜 패치가 제거 되었는지에 대한 설명으로 변경됩니다.
  • 해당 패치는 1년 동안 withdrawn 리스트에 로깅 됩니다. Withdrawn Patches Reports 를 참고하시기 바랍니다.
  • Sun Alert 이 배포되어 고객들에게 withdrawn 패치 이슈에 대해 공지 합니다. Sun Alert 은 withdrawn 패치가 설치된 시스템에서 취해야할 작업들에 대해 설명합니다.

    Sun Alert 은 발표된 Sun Alert 의 리스트에 나타납니다. Recent Sun Alerts 를 확인하시기 바랍니다.

Interactive 패치

설치 하기 위해 사용자의 상호작용이 요구되는 패치 입니다. 이 패치는 반드시 패치 README 파일에 지정된대로 특별한 설치 지시사항을 따라야 합니다.

Update 배포판과 스크립트 패치

썬은 정기적으로 솔라리스의 현재 배포판에 대한 업데이트를 제공합니다. 이러한 배포는 "Update" 배포판으로 알려져 있습니다. Update 배포판은 완전한 배포판으고 날짜로 표시 됩니다. 예를 들어 솔라리스10 6/06 이 될 수 있습니다.

Update 배포판은 솔라리스10 3/05 같은 본래의 배포판을 만드는 전체 패키지들로 구성되어 있고 현재까지의 모든 패치들과 미리 적용된 패치 그리고 새로운 기능들이 포함되어 있습니다.

미리 적용되는 패치의 과정상 몇몇 패치들은 배포되지 않은 것들도 있습니다. 그러므로 Update 배포판의 몇몇 패치는 SunSolve 에서 발견할 수 없을지도 모릅니다. 이러한 패치들은 스크립트 패치라고 불립니다. 스크립트 패치는 버그 픽스 나 새로운 기능을 제공하지는 않지만 이미지 생성상에서 발견된 이슈들을 수정하는 픽스를 제공합니다. 결과적으로 스크립트 패치는 고객들에 의해 사용가능하지 않습니다. 왜냐하면 Update 배포판을 만드는 과정 이외에는 쓸모가 전혀 없기 때문입니다.


패치의 특징들

다음 섹션에서는 패치의 특성들에 대한 기본적인 정보를 제공합니다.

README 파일 내의 키워드

키워드가 제공됨으로써 사용자들이 그들의 환경에는 어떠한 것들이 적용이 가능한지를 인식할 수 있도록 도와 줍니다. 가장 중요한 키워드는 "Security" 입니다. Security 는 패치가 보안에 대한 픽스를 포함하고 있음을 의미하고 그러므로 매우 중요하게 고려되어야 합니다. 다른 키워드는 영향을 받는 서브 시스템, 하드웨어 플랫폼, 혹은 유저 커맨드들을 포함하고 있을 것입니다.

패치 메타데이타

패치들은 패치의 속성을 설명하는 메타데이타와 연관되어 있습니다. 메타데이타는 “설치 후 재부팅” 혹은 “싱글-유저 모드 설치 필요” 같은 특별한 취급이 필요한 요구사항들을 포함하고 있습니다. 이러한 속성들은 README 파일에 텍스트 형태로 번역되어 있고 반드시 읽어야 합니다.

솔라리스 패치 유틸리티는 또한 pkginfopkgmap 파일에 포함된 메타데이타들을 활용 합니다.

논-글로벌 존을 위한 패치 메타데이타

패치에는 특정 솔라리스 존에 대한 메타데이타를 포함하고 있어서 존 환경에서의 올바른 패치를 가능하도록 합니다. 자세한 정보는 다음의 참고자료에서 찾으실 수 있습니다:


패치 의존성 (상호연관성)

패치에서 제겅되는 기능, 즉 버그 픽스 혹은 새로운 기능은 다른 패치에서 제공되는 기능들과 서로 상호연관성이 있을 수 있습니다.

이러한 상호연관성은 패키지 내의 pkginfo 파일 내에 3가지 필드들에 의해 결정 됩니다:

  • SUNW_REQUIRES 필드는 패치 의존성을 구분 합니다. 이러한 필수 요구 패치들은 반드시 해당 패치를 설치하기 전에 설치되어 있어야 합니다.
  • SUNW_OBSOLETES 필드는 패치내에 누적된 내용을 구분 합니다. 이 새로운 패치는 기존의 패치들을 쓸모 없게 만듭니다.
  • SUNW_INCOMPAT 필드는 이 패치와 호환되지 않는 패치들을 구분 합니다. 그러므로 동일한 시스템에는 설치될 수 없습니다.

이 필드들은 솔라리스 patchaddpatchrm 커맨드에 의해 사용되어 져서 자동으로 패치하려는 타겟 시스템의 일관성을 보장합니다. 해당 필드들은 패치의 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 패치 참고자료

설명

정보

Patching documentation hub 사이트는 솔라리스 패치에 관한 다양한 FAQ, 절차서 그리고 일반적인 정보를 제공합니다.

솔라리스10 1/06 배포판에서 썬은 새로운 패치 관리 툴인 썬 커넥션을 포함시켰습니다. 이 툴은 시스템을 분석하고 적절한 패치를 적용시켜 줍니다.

소규모 패키지에 대한 좀 더 자세한 정보를 포함하고 있는 패키지 오버뷰:

컨트롤 파일들과 프로시져 스크립트를 포함하고 있는 패키지 컴포넌트들에 대한 정보:

패치 프로시저 스크립트에 대한 자세한 정보:

썬 교육 코스는 http://www.sun.com/training/ 에서 살펴 보실 수 있습니다:

  • Solaris System Administration for Experienced UNIX Administrators (STS-276)
  • Solaris Operating System Administration for Experienced HP-UX and Tru64 Administrators (STS-277)
  • Solaris Operating Environment Essentials for System Maintainers (SM-101)
  • Make the Transition to the Solaris 10 Operating System - CD Package (PK-SA-210C-S10)
  • Make the Transition to Solaris 10 (PK-SA-210-S10)
  • Sun Certified Security Administrator for Solaris 10 OS (CX-310-303)

Support:

오픈솔라리스 패치 정보:

토론:

위키:

관련 정보들:


저자 : Lynne Thompson

이 글의 영문 원본은
http://www.sun.com/bigadmin/sundocs/articles/patch-types.jsp?cid=e4692

에서 보실 수 있습니다.
2008/01/16 15:24 2008/01/16 15:24

TRACKBACK :: http://blog.sdnkorea.com/blog/trackback/490

댓글을 달아 주세요

[로그인][오픈아이디란?]

◀ Prev 1  ... 165 166 167 168 169 170 171 172 173  ... 624  Next ▶