SUSE Manager로 고급 패치 라이프싸이클 관리

현재 많은 조직에서 시스템 관리자가 지속적으로 겪을 수 있는 가장 큰 어려움 중 하나는 시스템을 패치된 상태로 안전하게 유지하는 것입니다. 독점 및 오픈 소스 소프트웨어 회사는 자체 소프트웨어 제품에서 발견된 결함을 수정하는 업데이트를 제공하느라 항시 애쓰고 있습니다.

이러한 압박 외에 PCI-DSS(Payment Card Industry Data Security Standard), SOX(Sarbanes-Oxley), HIPAA(Health Insurance Portability and Accountability Act), FIPS 140(Federal Information Processing Standard)과 같은 적합성 계획의 요구사항을 따라야 하는 어려움도 있습니다. 이러한 “표준”은 대부분 패치 빈도나 기간을 지시하는 규칙을 포함하고 있고, 이러한 일정은 특정 패치의 심각도 수준 때문에 수정되는 경우가 많습니다.

대기업이든 소기업이든 광범위한 컴퓨터 인프라를 기반으로 끊임없이 변하는 응용 프로그램 상황에 의존하고 있습니다. 이러한 응용 프로그램은 물리 및 가상 호스트를 포함하고 복잡한 응용 프로그램 스택이 있을 수 있습니다. 또한 특정 커널 버전 종속성이나 엄격한 가동 시간 요구사항이 있을 수 있고, 특정 런타임 환경(예: Java)과 연결될 수도 있습니다. 이 응용 프로그램은 특정 Linux OS 릴리스에서만 인증을 받을 수 있습니다. 또는 일련의 특별한 구성 요구사항이 있을 수 있습니다. 이러한 호스트를 나머지 호스트와 별도로 설정하는 추가 강화 또는 플랫폼 요구사항이 있을 수 있습니다.

이 외에도 많은 회사가 변경 사항 테스트 또는 유효성 검사를 고려하여 “프로덕션”을 미러링하는 “개발” 또는 “QA” 상황과 같은 중복된 호스트 환경을 조성해 왔습니다. 이는 관리하고 패치하고 보고할 완결된 호스트 세트가 최소 한 개 더 있음을 의미합니다. 이로 인해 분기별로(중요 취약점의 경우 더 자주) 모든 호스트에 패치를 적용할 것을 자주 요구하는 엄격한 패치 일정을 충족해야 하는 어려움이 가중됩니다.

이 모든 문제를 해결하고 복잡한 엔터프라이즈 Linux 환경에 대한 제어권을 다시 확보하는 방법이 있을까요?

1.4 지침 #

 

본 안내서는 SUSE Manager 2.1에 기반을 둔 것이지만 SUSE Manager 3.0에서도 사용할 수 있습니다. 본 문서에서는 Salt Minion의 세부 사항은 강조하지 않을 것이며, 이 문제가 변경되는 경우 채널 조직 및 패치 조작이 어떻게 처리되는지에 대해서도 다루지 않을 것입니다.

새로 설치할 필요는 없지만, 사용자에게 작동하는 SUSE Manager 환경과 몇 가지 등록 호스트, 그리고 용어 및 기능에 대한 올바른 지식이 있다고 가정합니다. https://documentation.suse.com/suma/3.2/에서 볼 수 있는 SUSE Manager 문서는 자주 업데이트되는 훌륭한 정보원입니다. 이 문서를 참조하면 혼란스러워 보이는 모든 프로세스를 명확히 이해할 수 있습니다. 본 문서에 자세히 설명된 여러 가지 구현 단계는 SUSE 제품 문서에 있는 절차, 기능 또는 단계별 “방법”에 따른 향상된 예시입니다.

참고: 구현 테스트

일부 고급 기능(예: spacecmd 또는 XMLRPC API 사용)에 대해 더 자세히 설명하겠지만 완전한 설명은 아닐 수 있습니다. 있는 그대로 사용하거나 특정 환경이나 필요에 맞게 수정할 수 있는 몇 가지 코드 예시를 부록에 포함할 것입니다. 하지만 이 예시는 보증 없이 제공되며 모든 구현에 완벽하게 맞을 것으로 기대해서는 안 됩니다. 프로덕션 사용 전에 특정 구현을 항상 테스트하십시오.

다음 섹션에서는 시나리오 섹션에 정의된 요구사항을 충족하기 위해 SUSE Manager를 설정하는 방법에 대해 설명합니다. 먼저 이 요구사항을 충족하기 위해 개발된 아키텍처(및 구성 요소)에 대해 기술하고, 이어서 이를 직접 생성할 수 있는 단계에 대해 설명합니다. 본 안내서의 각 구성 요소는 여기에 설명된 특정 시나리오에서 다른 구성 요소와 함께 사용되어 포괄적인 솔루션을 제공하지만, 개별적으로 사용하면 자체 솔루션 요구 사항을 충족하는 데 도움이 될 수 있습니다.

함께 살펴볼 것은 다음과 같습니다. 우리는 SUSE Manager를 설정하고 패치 라이프싸이클 관리에 도움이 될 일련의 절차, 프로세스 및/또는 도구(스크립트)를 생성해야 합니다. 이 작업에는 우리가 사용하는 SUSE Linux Enterprise Server의 여러 버전을 위해 SUSE가 제공한 “업데이트” 채널에서 패치 아카이브 채널을 생성(최적의 “자동” 생성 포함)하는 과정이 포함됩니다. 이 패치 아카이브는 SUSE의 패치 프로모션을 위한 원본이지만 과거에 배포된 패치 세트에 기반을 둔 테스트 환경을 설정하기 위한 원본일 수도 있습니다. 이를 사용해 모든 이전 패치 세트에 패치된 호스트로 가득 찬 랩을 생성하는 등의 방법을 통해 오류 상황을 해결할 수 있습니다. 또한 시간이 표시된 패치 세트로 정의된 적합성을 입증하고 적합성에 대한 명확한 뷰를 시각화할 수 있습니다.

또한 일련의 소프트웨어 채널을 생성해야 합니다. 이 채널은 우리가 배포하기로 결정하면 업데이트를 수신합니다. 각 상황은 오직 이전에 “검증된” 상황으로부터 업데이트를 수신해야 합니다. 따라서 DEV에 배치되어 시스템에서 테스트를 받습니다. 그런 다음, QA로 이동하여 거기서 테스트를 받습니다. 끝으로 PROD로 이동합니다. 분기마다 모든 것이 다시 시작되고, 우리는 예외 발생 시 이를 처리합니다. 각 예외는 적합성에 대한 명확한 뷰를 보장하기 위해 모든 예외를 교정하여 패치가 최대한 빨리 재도입되게 한다는 항상적인 목표에 따라 확립된 다른 프로세스로 추적됩니다.

분기별 배포를 가로막는 다른 요인으로 분기별 1회보다 더 자주 배포해야 하는 “중요” 보안 패치 릴리스를 들 수 있습니다. 이러한 추가 일정을 처리하려면 모든 중요 패치와 그 배포를 추적하기 위한 추가 채널을 생성해야 합니다. 중요 패치로 간주해야 할 패치는 CVSS 점수가 7.1 이상이거나 기업 보안 조직이 규정한 CVE입니다. 우리가 현재 관리하는 SUSE Linux Enterprise Server 버전은 SUSE Linux Enterprise Server 11 SP3와 SUSE Linux Enterprise Server 12 두 가지입니다. 우리는 서비스 팩 마이그레이션을 지원하기 위해 SUSE Manager를 사용할 계획이므로 우선 SUSE Linux Enterprise Server 11 SP4 처리를 위한 설정 작업을 하는 것이 가장 좋습니다. 또한 우리는 SUSE Linux Enterprise Server 11 SP3의 32비트 및 64비트 Intel/AMD 버전을 유지하고 있으므로 이 두 버전을 모두 처리해야 합니다.

우리가 관리해야 할 환경은 기업(CORP)과 스토어(STORE) 두 가지입니다. 우리는 별도의 SUSE Manager 조직을 생성하여 시스템 관리자에게 그들이 담당하고 있는 호스트에 대한 독점적인 뷰를 허용하였습니다. 각 SUSE Manager 조직에는 그들이 패치 테스트/프로모션에 사용하는 세 가지 상황(DEV, QA, PROD)이 있습니다.

호스트가 적절하고 가장 적합한 영구적 역할에 등록되게 하기 위해 활성화 키 및 부트스트랩은 각 SUSE Manager 조직(각 환경)과 각 상황에 대해 생성되어야 합니다. 예를 들어 부트스트랩 스크립트는 SUSE Linux Enterprise Server 11 SP3(64비트) DEV 호스트를 해당되는 조직에 등록하고 다시 조작할 필요가 없어야만 하는 적절한 기본 및 하위 채널을 추가합니다. 자동화가 기본 설정되어 있습니다. 앞서 언급했듯이 스크립트나 일정이 지정된 작업을 사용하면 솔루션이 크게 향상되고 관리 직원의 부담이 경감됩니다.

2.1 아키텍처 #

 

아키텍처 및 채널의 개괄적 윤곽은 다음과 같습니다.

참고: 접두어 사용

여기에 나열된 모든 기본 채널의 경우 이것은 SUSE 벤더 채널의 복제 트리일 수 있습니다. 따라서 이름에 접두어-가 포함됩니다. 이를 통해 다음과 같은 채널 생성 섹션에 설명된 서비스 팩 처리를 지원할 수 있습니다.

• SUSE Manager 조직

  • 기본값(기본) - 1

    • 32비트 아카이브 채널(공용)

      • Q2 - 06-30-2015 - i586용 SLES 11 SP3 업데이트

      • Q3 - 09-30-2015 - i586용 SLES 11 SP3 업데이트

    • 64비트 아카이브 채널(공용)

      • Q2 - 06-30-2015 - x86_64용 SLES 11 SP3 업데이트

      • Q3 - 09-30-2015 - x86_64용 SLES 11 SP3 업데이트

      • Q2 - 06-30-2015 - x86_64용 SLES 12 업데이트

      • Q3 - 09-30-2015 - x86_64용 SLES 12 업데이트

    • SUSE 기본 채널 내 복제 세트 또는 하위 채널

    • 기본: i586용 SLES 11 SP3 풀

      • DEV - 현재 패치 세트 - i586용 SLES 11 SP3 업데이트

      • QA - 현재 패치 세트 - i586용 SLES 11 SP3 업데이트

      • PROD - 현재 패치 세트 - i586용 SLES 11 SP3 업데이트

      • 패치 예외(구독 금지) - SLES 11 SP3 i586

      • 보안 ASAP 예외 - SLES 11 SP3 i586

    • 기본: x86_64용 SLES 11 SP3 풀

      • DEV - 현재 패치 세트 - x86_64용 SLES 11 SP3 업데이트

      • QA - 현재 패치 세트 - x86_64용 SLES 11 SP3 업데이트

      • PROD - 현재 패치 세트 - x86_64용 SLES 11 SP3 업데이트

      • 패치 예외(구독 금지) - SLES 11 SP3 x86_64

      • 보안 ASAP 예외 - SLES 11 SP3 x86_64

    • 기본: x86_64용 SLES 12 SP3 풀

      • DEV - 현재 패치 세트 - x86_64용 SLES 12 업데이트

      • QA - 현재 패치 세트 - x86_64용 SLES 12 업데이트

      • PROD - 현재 패치 세트 - x86_64용 SLES 12 업데이트

      • 패치 예외(구독 금지) - SLES 12 x86_64

      • 보안 ASAP 예외 - SLES 12 x86_64

    • 패치 예외 채널(위와 동일)

      • 기본 채널당 - 각 “업데이트” 채널에 채널 한 개:

        • 예제:

          • 패치 예외(구독 금지) - SLES 11 SP3 i586

          • 보안 ASAP 예외 - SLES 11 SP3 i586

  • 기업(CORP) - 2

    • 모든 공용 채널은 여기에 표시됨

    • 개인 채널은 조직별로 공유할 수 있음

  • 스토어(STORE) - 3

    • 모든 공용 채널은 여기에 표시됨

    • 개인 채널은 조직별로 공유할 수 있음

0 0 30 6,9 * /path/to/archive-create-script

00 0 31 3,12 * /path/to/archive-create-script

0 0 1 1,4,7,10 * /path/to/archive-create-script

2.3 패치 프로모션 싸이클 #

 

패치와 패치에 포함된 패키지가 SUSE에서 취득되는 방식, 다운로드 후에 이동하는 곳, SUSE Manager 내에서 정렬되는 방식을 이해하는 것이 고급 패치 라이프싸이클 시스템을 설정하는 데 가장 중요합니다. 기본적으로 SUSE Manager는 자체 채널 세트를 SUSE Linux Enterprise Server 및 확장의 특정 버전 및 아키텍처를 기준으로 정렬합니다.

예를 들어 SUSE Linux Enterprise Server 11 SP3 x86_64용 SUSE Manager 안에 있는 기본 채널 세트에는 “풀” 채널이라고 하는 상위 또는 기본 채널이 포함되어 있습니다. 이 채널에는 기능적 측면에서 SUSE Linux Enterprise Server 11 SP3 64비트용 설치 DVD와 동일한 패키지가 포함되어 있습니다. 이 풀 채널 아래에는 SUSE Manager 도구 채널이라고 하는 SUSE Manager 클라이언트 패키지용 채널과 이 경우 x86_64용 SUSE Linux Enterprise Server 11 SP3 업데이트라고 하는 업데이트 채널이 포함된 모든 “하위” 채널이 있습니다.

관리 호스트가 구독하는 일반 채널 세트에는 상위 채널(풀), SUSE Manager 도구 채널과 업데이트 채널이 최소 한 개씩 포함됩니다. SUSE Linux Enterprise Server 11 SP2와 같은 경우 여기에는 SUSE Linux Enterprise Server 11 SP1 풀, SP1 업데이트 채널, SP2 코어 채널, SP2 업데이트, SP2 확장 스토어, SP2 SUSE Manager 도구 채널이 포함됩니다.

참고: 장기 서비스 팩 지원(LTSS)

SUSE Linux Enterprise Server SP1 및 SP2는 자체 LTSS 단계에 있기 때문에 SUSE에서 생성되는 비 LTSS 업데이트가 더 이상 없습니다. 따라서 회사가 보유할 수 있는 모든 SP1 또는 SP2 호스트는 LTSS를 구매하고 LTSS 업데이트 채널을 사용해 추가 패치 및 지원을 받아야 합니다. 자세한 내용은 http://www.suse.com/lifecycle에서 보실 수 있습니다.

다음은 패치 프로모션 프로세스를 설명하는 그래픽입니다.

그림 1: 패치 프로모션 프로세스 #

 

2.6 채널 #

 

위 아키텍처 섹션에서 설명한 것처럼 패치 프로모션 프로세스를 지원하기 위해 몇 가지 사용자 정의 채널을 생성할 것입니다. 이 채널은 (SUSE 업데이트 채널의 복제로 생성된) 아카이브를 저장하고 예외 패치도 저장합니다. 각 상황에 대해 프로모션된 패치를 보유할 사용자 정의 채널이 생성됩니다. 싸이클마다 패치가 프로모션되면서 이 채널에는 갈수록 더 많은 컨텐트가 저장됩니다.

예를 들어 1분기(Q1) 동안 아카이브 채널에는 159개의 패치가 저장되고, 이 패치는 SUSE Linux Enterprise Server 11 SP4용 DEV 업데이트 채널로 병합됩니다. SUSE가 지속적으로 패치를 릴리스하는 과정에서 다음 분기(예: Q2)의 아카이브가 생성되면 이 아카이브에는 모든 Q1 패치와 130개의 추가 패치를 합해 총 289개의 패치가 저장됩니다. 병합 기능은 130개의 새 패치 (및 연결된 패키지)를 받아들여 그다음 패치 싸이클이 진행되는 동안 DEV 업데이트 채널에 추가합니다.

각각 새 패치 싸이클은 특정 상황의 “현재 업데이트” 채널에서 사용 가능한 패치를 업데이트합니다. 이러한 방식으로 각 후속 패치 프로모션은 새 업데이트를 추가하고, 이 업데이트는 채널을 구독하는 모든 호스트에 적용할 수 있습니다.

예외 채널은 개별 패치를 관리하고, 개별 패치를 상황 업데이트 채널 중 하나, 또는 아카이브 채널 중 하나에서 복사하는 방식으로 채워집니다. 패치는 예외 채널로 복사한 후 업데이트 채널 또는 아카이브에서 제거할 수 있습니다.

2.6.1 채널 생성 #

 

아카이브 채널:#

사용자 정의 채널은 SUSE Manager에서 비어 있는 “새” 채널 또는 “복제”로 생성됩니다. 기술적으로는 복제 채널도 빈 상태로 생성할 수 있지만, 이 경우 SUSE 업데이트 채널, 패치, 그리고 패치가 참조하는 패키지가 원본인 컨텐트로 아카이브 채널을 생성합니다. 각 아카이브 채널은 빈 기본 채널에 상주합니다. 기본 채널은 SUSE Manager가 관리하는 각 프로세서 아키텍처(IA-32, x86_64, s390x, PPC 등)에 대해 생성됩니다. 기본 채널에는 다양한 버전의 SUSE Linux Enterprise Server에 부합하는 여러 아카이브가 있지만 모두 동일한 프로세서 아키텍처입니다.

기본 아카이브 채널 생성:

SUSE Manager가 관리하는 호스트가 사용하는 각 프로세서 아키텍처에 대해 “32비트 아카이브 채널”과 “64비트 아카이브 채널”이라는 빈 채널을 생성합니다.

1. 웹 UI에서 “[채널]”을 클릭하고 하위 메뉴인 “[소프트웨어 채널 관리]”를 클릭한 후 “[+채널 생성]”을 클릭합니다.

2. 채널 레이블은 반드시 “아키텍처-패치-아카이브-채널” 형식으로 보관해야 합니다. 예를 들어 64비트 채널 레이블은 “x86_64-패치-아카이브-채널”로 표시해야 합니다.

   

   중요: 채널에 레이블 지정

   이 채널에 적절한 레이블을 지정하지 않으면 예시 아카이브 스크립트가 (수정 없이는) 제대로 작동하지 않게 됩니다. SUSE Manager는 채널 “레이블”에 대해 문자(숫자는 안 됨)로 시작하고 공백이 없는 소문자로 이루어져야 한다는 등 매우 엄격한 요건을 적용합니다.

   “x86_64”로 시작하는 레이블을 생성하는 이 예시에서는 32비트 채널이 “i586” 또는 이와 비슷한 것일 수 있습니다.

3. 이 아카이브 채널은 상위 채널“이므로” “상위가 없습니다”.

4. 이 채널에 적절한 아키텍처를 선택합니다(예: 64비트인 경우 x86_64, 32비트인 경우 IA-32).

5. 이 채널에 대해 공용 라디오 버튼을 선택하여 모든 조직에 표시되게 합니다.

6. 배포한 SUSE Linux Enterprise Server의 각 아키텍처 유형에 대해 이를 반복합니다.

복제 아카이브 채널을 생성합니다.

사용되는 SUSE Linux Enterprise Server의 각 버전에 대해 복제 채널을 생성합니다.

1. 웹 UI에서 “[채널]”을 클릭하고 하위 메뉴인 “[소프트웨어 채널 관리]”를 클릭한 후 “[채널 복제]”를 클릭합니다.

2. 원본으로 아카이브를 생성하고자 하는 SUSE Linux Enterprise Server 버전의 SUSE “업데이트” 채널을 선택합니다.

3. 모든 컨텐트/패치에 대해 라디오 버튼을 선택해야 합니다.

4. 시간/날짜와 아카이브에 포함된 것(예: “Q3 - 2015년 9월 30일 - x86_64용 SLES 11 SP3의 아카이브”)을 알 수 있도록 채널에 적절한 이름을 지정합니다.

5. 다음 예시와 같이 적절한 구문을 사용해 레이블을 생성합니다.

   q3-09-30-2015-archive-sles11sp3-x86_64

6. 중요: 복제를 포함할 적절한 기본 아카이브 채널을 선택합니다.

7. 요약 및 설명 필드에 채널에 대한 적절한 설명을 입력합니다.

8. 완료 후 “[채널 생성]”을 클릭합니다.

9. 아래로 스크롤하여 공용 라디오 버튼을 선택하고 “채널 업데이트”를 클릭합니다.

10. 각 아키텍처의 SUSE Linux Enterprise Server 각각에 대해 이를 반복합니다.

선택 사항: 다음과 같이 spacewalk-clone-by-date를 사용해 날짜가 과거인 아카이브 채널을 생성할 수 있습니다.

spacewalk-clone-by-date 유틸리티와 함께 사용할 수 있는 예시 원본 파일의 부록을 참조하십시오. 다음과 같이 이 구성 파일을 사용해 특정 날짜 범위의 복제 채널을 채널 컨텐트용 필터로 생성할 수 있습니다.

1. 이 유틸리티는 다음 구문으로 호출됩니다.

   spacewalk-clone-by-date -c "config file"

2. 날짜가 과거로 되어 있는 각 아카이브 채널에 대해 이를 반복하여 구성 파일이 적절한 날짜와 채널 원본/대상 이름에 부합하도록 수정하십시오.

2.6.1.1 업데이트 및 예외 채널로 서비스 팩 마이그레이션 지원 #

 

서비스 팩 마이그레이션 기능 이용 시 일관성 있는 예상 동작을 허용하는 채널 세트를 관리하는 방법으로 널리 용인되는 것이 몇 가지 있습니다. 이 기능은 특정 호스트의 소프트웨어 탭에서 찾으실 수 있습니다. 이 기능을 이용해 한 번 클릭하는 방식으로 특정 호스트의 서비스 팩을 업데이트할 수 있습니다. 본 문서에 설명된 패치 라이프싸이클 메소드를 사용하는 경우 서비스 팩 마이그레이션 기능 사용 시 몇 가지 어려움을 겪을 수 있습니다. 서비스 팩 마이그레이션을 수행하기 위해 특정 호스트를 선택하면 UI는 마이그레이션 작업을 위해 구독할 필수 “하위” 채널 세트를 제안(지시)합니다. 이러한 필수 하위 채널(UI에서 회색으로 표시)은 특정 버전의 SUSE Linux Enterprise Server에 대해 SUSE가 제공하는 업데이트 채널을 일반적으로 포함합니다.

다음 스크린샷을 참조하십시오.

그림 2: 서비스 팩 마이그레이션 #

 

여기에 설명된 패치 라이프싸이클 프로세스를 사용할 수 있게 허용하려면, 그리고 서비스 팩 마이그레이션의 기능을 사용하려면 회사에서 사용 중인 SUSE Linux Enterprise Server 제품 버전의 전체 복제 세트를 생성하는 것이 제일 나은 방법입니다. 이것은 때로 복제 트리라고 하며 softwarechannel_clonetree라는 동일한 이름의 spacecmd 명령을 사용해 쉽게 생성할 수 있습니다.

전체 복제 트리는 기본/상위 채널(일반적으로 풀이라고 함)과 현재 그 아래에 있는 모든 하위 채널을 포함합니다. 예를 들어 SUSE Linux Enterprise Server 11 SP3 풀 x86_64 채널을 원본으로 사용하는 경우 자체 접두어를 복제 트리 명령에 제공하면 풀과 모든 하위의 사본을 만들어 모든 채널 이름 및 레이블의 첫머리에 접두어를 추가합니다.

아래에 있는 원본 SUSE Linux Enterprise Server 11 SP3 x86_64 채널과 그 옆에 접두어 버전 “Chameleon_Co-”가 있는 복제 트리의 이미지를 참조하십시오.

그림 3: Chameleon Corporation의 전체 소프트웨어 채널 목록 #

 

spacecmd softwarechannel_clonetree라는 명령은 원본 및 접두어 정보를 직접 제공하여 직접 호출하거나 spacecmd 셸 자체 내에서 명령을 호출하여 대화식으로 호출할 수 있습니다.

예:

spacecmd -u <SMadmin> -- softwarechannel_clonetree -s sles11-sp3-pool-x86_64 -p "my_company-"

참고: <SMadmin>

<SMadmin>을 SUSE Manager webUI 관리자 사용자 이름으로 교체하십시오!

이 명령을 실행하면 접두어가 “my_company”인 SUSE Linux Enterprise Server 11 SP3 x86_64 채널의 전체 세트가 생성됩니다.

SUSE Linux Enterprise Server 각 버전에 이 프로세스를 반복합니다. 이어서 서비스 팩 마이그레이션 기능을 사용할 때 대상 버전인 SUSE Linux Enterprise Server의 자사 버전을 선택하고 호스트가 있는 상황에 적절한 하위 채널을 선택할 수 있습니다(아래 설명 참조).

그런 다음, 모든 패치/패키지를 제거하여 복제된 업데이트 채널을 수정하고, 이어서 병합 스크립트 프로세스를 사용해 “현재 패치 세트”를 필수 업데이트 채널로 병합하면 됩니다. 이렇게 하면 서비스 팩 마이그레이션 작업을 수행해도 현재 프로모션된 자신의 패치 세트를 그대로 유지할 수 있습니다. 아니면 SP 마이그레이션이 항상 “필수” 업데이트 하위 채널의 최신 패키지로 업데이트됩니다.

패키지가 227개인 SUSE Linux Enterprise Server 11 SP4의 Q3 패치 아카이브, 패키지가 234개인 SP4의 SUSE 업데이트 채널, 패키지가 없는 SP4 업데이트의 Chameleon Corporation 버전을 보여주는 아래 스크린샷을 참조하십시오.

그림 4: SUSE 및 Chameleon Corporation의 소프트웨어 채널 목록 일부 보기 #

 

앞으로 나올 섹션에서는 사용자 정의 “현재 업데이트” 생성과 병합 스크립트 사용 방법에 대해 설명하겠습니다. 자체 프로모션 패치 세트를 사용한 서비스 팩 마이그레이션의 경우 “프로덕션” 채널의 “현재” 패치 아카이브를 “업데이트” 채널로 병합하여 마이그레이션 작업에 사용되게 하거나 “업데이트” 채널을 항상 빈 상태로 두고 현재 업데이트 채널을 “선택 사항인 하위 채널” 선택에 추가하십시오.

빈 “업데이트” 채널과 입력된 “현재 업데이트”를 통해 서비스 팩 마이그레이션이 예상대로 이루어지고 “프로덕션”으로 간주되는 것이 무엇이든 그것보다 새로운 패키지 버전으로 시스템을 패치하지 않도록 보장할 수 있습니다. 사용자 정의 “업데이트” 채널 및 병합 스크립트 프로세스에 관해서는 앞으로 나올 섹션에서 자세히 설명드리겠습니다.

“현재 업데이트” 채널:#

이제 관리 호스트가 상황에 따라 구독할 “현재 업데이트” 채널을 생성합니다(예: “DEV - 현재 업데이트 - SLES 11 SP3 x86_64용” 또는 “PROD - 현재 업데이트 - SLES 12 x86_64용”). SUSE Linux Enterprise Server 각 버전의 상황 채널 전체 세트가 있고, 새로 시작할 빈 채널이 있습니다. 다음과 같이 “새” 채널을 생성한 후 이 채널을 “복제”하는 옵션 기능을 사용해 필요한 입력 양을 줄입니다.

1. “[소프트웨어 채널 관리]” 하위 메뉴에서 “[채널 생성]”을 클릭합니다.

2. SUSE Linux Enterprise 풀 채널 중 하나에 채널을 생성합니다. 자체 복제 세트가 없다면 이 풀 안에 생성합니다.

3. 채널을 공용으로 수정합니다.

4. 이 새 채널(업데이트 없음)을 남아 있는 상황에 각각 “현재 업데이트” 채널로 복제하고 각각에 적절한 상황 접두어(예: “DEV - ”, “TEST - ”, “PROD - ” 등)를 붙입니다.

5. 결국 관리하고자 하는 각 SUSE Linux Enterprise Server 버전에 전체 상황 세트가 있는 상태가 되어야 합니다. SUSE Linux Enterprise Server 11 SP1 및 SP2 채널에 유념하십시오. 이로 인해 전체 집합이 두 배(LTSS 사용 시 네 배)가 됩니다. 하지만 SP1 및 SP2 업데이트 채널은 더 이상 업데이트되고 있지 않으므로 현재는 정적 채널로 구독할 수 있습니다. (2.3절 “패치 프로모션 싸이클”에서 LTSS에 관한 메모를 참조하십시오.)

그림 5: “현재 업데이트” 채널의 예시 스크린샷 #

 

“예외” 채널:#

이제 병합되는 SUSE Linux Enterprise Server의 각 버전에 대해 두 개의 예외 채널을 생성합니다. 아키텍처(예: 아카이브 채널 기반)에 고유한 혼합 채널을 생성하는 것이 가능할 수 있지만 어떤 배포에서 패치 예외가 발생한 것인지 추적하는 일은 번거로울 수 있습니다. 여러 버전의 SUSE Linux Enterprise Server에서 패치/패키지를 혼합하는 경우 이러한 패치를 추적하여 해결한 후 패치 워크플로로 재도입하기가 더 어렵습니다. 패치의 출처인 SUSE Linux Enterprise Server의 버전에 대해서만 예외 채널에 패치를 배치하는 것이 훨씬 더 쉽습니다. 다음과 같이 “패치 예외” 및 “보안 ASAP 예외” 채널을 생성합니다.

1. “[소프트웨어 채널 관리]” 하위 메뉴에서 “[채널 생성]”을 클릭합니다.

2. SUSE Linux Enterprise Server 풀 채널 중 하나에 “패치 예외 - 구독 금지” 채널을 생성합니다. 자체 복제 세트가 없다면 이 풀 안에 생성합니다. 이 채널은 상황 채널 옆에 상주합니다.

3. 채널을 공용으로 수정합니다.

4. 위와 같이 “보안 ASAP 예외” 채널을 생성합니다. 이 채널 역시 상황 및 패치 예외 채널 옆에 상주합니다.

5. SUSE Linux Enterprise Server 11 SP1 및 SP2의 경우 유념할 점은 이들이 동일한 SP1 풀 기본 채널에 상주하므로 각 서비스 팩에 예외 및 보안 예외 채널이 있다는 것입니다.

그림 6: “예외” 채널의 예시 스크린샷 #

 

0 0 30 6,9 * /path/to/the/archive/script

0 0 31 3,12 * /path/to/the/archive/script

본 안내서에서는 SUSE Manager를 활용해 다음과 같은 이점을 제공하는 패치 라이프싸이클 관리에 대한 접근 방식을 설명합니다.

3.1 프로세스 워크플로 예시 #

 

다음은 패치 프로모션 및 예외 프로세스를 위한 워크플로로 제안할 수 있는 몇 가지 예시입니다. 이 예시는 특정 운영 그룹의 기존 프로세스 세트에 더 적합하게 수정할 수 있습니다.

워크플로 1: 패치 프로모션 프로세스#

패치 프로모션 프로세스는 다음 샘플 단계를 따릅니다.

표 1: 패치 프로모션 프로세스 #

 

해결 방법	프로세스	참고
검토	기존 달력을 참조해 패치 배포 시작일을 정합니다.	일반적으로 시작일은 새 분기가 시작될 때 발생하지만 배포 빈도 및 확정된 기간에 따라 달라집니다.
선택	패치 배포에 대한 SUSE Manager 조직과 환경 대상을 파악합니다.	이 예시의 시나리오에서는 이것이 CORP, STORE, NPE 중 하나가 될 수 있고, SUSE Manager 조직의 사용 여부에 따라 관리자가 호스트를 보려면 로그인해야 할 수 있습니다.
선택	패치가 적용될 SUSE Linux Enterprise Server 버전을 선택합니다.	패치 프로모션은 각 SUSE Linux Enterprise Server 버전에 대해 수행됩니다. 각 버전에는 패치가 프로모션되면서 거치는 자체 상황 채널 세트가 있습니다(DEV, TEST, QA, PROD 등).
병합	현재 아카이브를 초기 상황 (또는 선택한 상황)으로 병합합니다.	“스크립트 병합” 유틸리티 사용: 원본 채널(이 경우 아카이브) 및 대상 채널(시리즈를 시작할 DEV - 현재)을 선택합니다.
배포	현재 상황에서 구독한 호스트로 패치를 배포합니다.	패치가 병합되면 “현재” 채널을 구독한 호스트의 상태에 어느 패치가 현재 사용 가능한지 표시됩니다. 적절한 패치 명령을 실행하여 이 패치를 배포합니다.
테스트	최근에 배포된 패치를 수신한 호스트에 대한 테스트를 조율하거나 해당 팀/LOB에게 평가를 시작하라고 알립니다.	패치를 배포한 후 패치 배포의 성공 여부를 검증하기 위해 테스트 또는 검토 기간을 시작해야 합니다. 배포의 확실한 성공을 위해 조정 작업은 비즈니스 파트너와 함께 수행해야 합니다.
평가	이전에 한 병합/배포의 결과를 평가하고 다음 상황으로 나아갑니다. 최종 상황인 경우 완료되었음을 보고합니다.	패치 세트를 최종 상황에 이를 때까지 계속해서 각 상황으로 병합하고 배포합니다. 완료되었음을 보고합니다. 모든 호스트는 “녹색” 상태로 표시되어야 합니다.

워크플로 2: 패치 예외 프로세스#

패치 예외 프로세스는 다음 샘플 단계를 따릅니다. 다시 말씀드리지만 이 예시는 특정 운영 그룹의 기존 프로세스 세트에 더 적합하게 수정할 수 있습니다.

다음 표를 참조하십시오.

표 2: 패치 예외 프로세스 #

 

해결 방법	프로세스	참고
식별	패치 세트에서 잠재적으로 제거하기 위한 “예외”로 식별하려는 패치를 찾아냅니다.	SUSE Manager에서 검색 도구를 사용해 패치를 검색하거나 특정 아카이브 또는 상황 채널에 있는 패치를 찾아냅니다.
사본	SUSE Manager의 “채널 관리” 기능 사용: SUSE Linux Enterprise Server 특정 버전용 예외 채널을 선택하고 식별된 패치를 (이전 단계의) 원본에서 이 채널에 추가합니다.	패치 채널의 원본과 패치 예외 채널의 대상이 중요합니다. 이 단계는 SUSE Linux Enterprise Server의 다양한 버전에 반복할 수 있습니다. 패치의 잠재적 원본은 다음과 같은 채널일 수 있습니다. 아카이브 채널 상황 채널 SUSE 업데이트 채널
제거	SUSE Manager의 “채널 관리” 기능 사용: 이전 단계에서 추가한 패치를 찾기 위해 패치 “목록을 나열”합니다. 패치를 찾은 후 현재 단계 (또는 여러 단계)에서 패치를 제거합니다.	패치를 찾은 후 상황 채널에서 제거하면 구독한 호스트가 패치를 확인하고 적용 가능성을 보고하는 작업을 하지 못하게 됩니다.
추적	티켓을 제출하거나 확립된 프로세스를 시작하여 이 패치 예외를 추적합니다.	추적의 목표는 교정을 위한 예외 및 시도가 있음을 계속 인지하여 패치가 패치 배포 싸이클에 재도입되게 하는 것입니다.
교정	예외를 교정하는 작업을 합니다.	특정 예외에 대해 수정이 식별/생성되었다면 패치를 배포 워크플로에 재도입할 수 있습니다.
메모	예외는 단일 배포 싸이클 동안만 지속되어야 합니다. 다음 아카이브에도 이와 동일한 패치가 포함된다는 장점이 있습니다.	예외는 항상 임시 조건이어야 합니다. 패치를 배포할 수 없는 이유를 수정하기 위한 작업을 항상 수행해야 합니다. 예외가 있는 한 적합성이 위험에 처할 수 있기 때문입니다.

워크플로 3: 보안 패치 ASAP 프로세스#

보안 예외 프로세스가 이전 패치 예외 프로세스와 다른 점은 패치가 패치 배포 싸이클에 추가된다는 것입니다(현재 진행 중인 배포 중에 추가될 수 있음). 더 명확한 설명을 위해 또 하나의 프로세스 테이블과 몇 개의 SUSE Manager 인터페이스 스크린샷을 여기에 포함하였습니다.

다음 표를 살펴보십시오.

표 3: 보안 패치 ASAP 프로세스 #

 

해결 방법	프로세스	참고
식별	특정 상황 또는 패치 세트에 대한 잠재적 추가를 위해 “보안 예외”로 식별하려는 패치를 찾습니다.	SUSE Manager에서 검색 도구를 사용해 패치를 찾거나 SUSE Linux Enterprise Server의 특정 버전용 특정 업데이트 채널에서 패치를 찾습니다.
사본	SUSE Manager의 “채널 관리” 기능을 사용해 SUSE Linux Enterprise Server 특정 버전용 예외 채널을 선택하고 식별된 패치를 원본(이전 단계의 SUSE 업데이트 채널일 수 있음)에서 이 채널에 추가합니다.	보안 패치(SUSE 업데이트 채널)의 원본과 패치의 대상(보안 예외 ASAP 채널)이 핵심입니다. 이 단계는 SLES의 다양한 버전에 반복할 수 있습니다. 패치의 잠재적 원본은 다음과 같은 채널일 수 있습니다. 아카이브 채널 상황 채널 SUSE 업데이트 채널
배포	보안 예외 패치(여러 개일 수 있음)를 선택된 상황으로 배포하여 구독한 호스트에 배포합니다.	보안 패치가 상황 채널에 추가되면 "현재" 채널을 구독한 호스트의 상태에 어느 패치가 현재 사용 가능한지 표시됩니다. 적절한 패치 명령을 실행하여 이 패치를 배포합니다.
추적	티켓을 제출하거나 확립된 프로세스를 시작하여 이 보안 패치 예외를 추적합니다.	추적의 목표는 보안 패치 예외가 배포되었음을 계속 인지하는 것입니다. 이 패치는 다음 분기별 자동 생성 중에 일반 아카이브의 일부가 됩니다.
보고	보안 예외는 일반적으로 적합성 문제를 처리하기 위해 발생합니다. 배포 시 적합성 (감사) 보고서를 생성할 수 있습니다.	보안 예외는 일반 일정으로의 에스컬레이션으로 처리됩니다. 일반 작업 측면에서 보안 예외는 다음 아카이브의 일부가 되고 기본 일정의 일부로 배포됩니다. 그 결과 그다음 일반 배포에는 이 패치가 포함될 필요가 없습니다(이미 배포되어 있을 것이기 때문).

다음 스크린샷에서는 패치를 보안 ASAP 예외 채널, 특히 SLES 11 SP1 x86_64 버전에 추가하는 기능을 보여줍니다.

그림 9: 보안 ASAP 예외 채널에 패치 추가 #

 

이 스크린샷에서 특정 채널(이 경우 “DEV - 현재 - x86_64용 SLES11-SP1-LTSS-업데이트”)의 나열/제거 기능을 확인할 수 있습니다. 이 인터페이스에서는 패치가 채널에서 제거되어 표시되지 않으며 잠재적으로 예외 프로세스의 일부로 배포됩니다.

그림 10: 보안 ASAP 예외 채널에 패치 추가 #

 

Copyright ©2006–2020 SUSE LLC 및 작성자. All rights reserved.

GNU 무료 설명서 라이선스, 버전 1.2 또는 (사용자 선택에 따라) 버전 1.3의 조항에 따라 본 문서를 복사, 배포 및/또는 수정하는 권한이 허가됩니다. 그리고 각 항목에는 본 저작권 표시 및 라이선스가 설명된 고정(Invariant) 섹션이 있습니다. 라이선스 버전 1.2의 복사본은 “GNU 무료 설명서 라이선스” 섹션에 포함되어 있습니다.

SUSE, SUSE 로고 및 YaST는 미국과 기타 국가에서 SUSE LLC의 등록 상표입니다. SUSE 상표에 관해서는 http://www.suse.com/company/legal/을 참조하십시오. Linux는 Linus Torvalds의 등록 상표입니다. 본 문서에 언급된 기타 모든 이름 또는 상표는 해당 소유주의 상표 또는 등록 상표일 수 있습니다.

본 문서는 "SUSE 모범 사례"라는 문서 시리즈 중 일부입니다. 이 시리즈의 개별 문서는 SUSE의 직원과 타사가 자발적으로 작성한 것입니다.

본 문서의 모든 정보는 최대한 주의를 기울여 작성되었습니다. 그러나 이것이 문서의 정확성을 보장하지는 않습니다.

따라서 SUSE LLC, 그 계열사, 저자, 번역자 중 어느 누구도 있을 수 있는 오류나 그에 따른 결과에 책임을 지지 않는다고 명확히 진술할 필요가 있습니다. 아래에 명시된 내용은 문서를 게시할 때 준수해야 할 라이선스에 대한 주의를 환기하기 위한 것입니다.

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
 Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts". line with this:

with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.