SUSE Managerを使った高度なパッチライフサイクル管理
複数ランドスケープ環境でSUSE Managerを使って更新プログラムを管理する方法とアプローチ
1 概要 #
現在、多くの組織でシステムに最新のパッチを適用してセキュリティを確保することが、システム管理者が直面している最大の課題の1つとなっています。プロプライエタリソフトウェア企業とオープンソースソフトウェア企業では、自社のソフトウェア製品で見つかった不具合を修正する更新プログラムを提供するための作業を常に行っています。
また、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ランドスケープなど、重複するホスト環境を作成している企業が数多くあります。 「###」 ###「###」 ###「###」 ###つまり、管理やパッチ適用、レポートが必要な完全なホストセットが最低でも追加で1つ以上あるのです。これにより、通常は四半期ごと（重大な脆弱性がある場合はそれ以上の頻度）にすべてのホストにパッチ適用が必要な、綿密なパッチスケジュールに従うのがますます困難になります。
こうした問題すべてに対処して、複雑なエンタープライズLinux環境の制御を取り戻すための方法はあるのでしょうか。
1.1 SUSEのソリューション #
SUSE Managerには、自動化されたソフトウェア管理やシステムのプロビジョニングと監視など、最高クラスのLinuxサーバー管理機能が搭載されています。また、サーバーのパッチ適用と管理を標準化および自動化することで、一元的なLinux管理インフラストラクチャを実現します。こうした作業はスピーディーに実行できてエラーも発生しにくいため、ITスタッフの生産性が向上してサーバーのダウンタイムも削減されます。
1.1.1 用語の定義 #
このドキュメントでは、複数あるLinuxホストのグループの1つを指す場合に「ランドスケープ」という単語を使用します。この単語は、ホストの役割/質を定義するためにエンタープライズソフトウェア環境で一般的に使用されています。たとえば、本番（PROD）、開発（DEV）、品質保証（QA）、ユーザー受け入れ/テスト（UAT）などを指す場合があります。
「環境」という言葉も使われています。このドキュメントでは、コーポレート（CORP）、ストア（STORE）、NPE（非本番環境）など、Linuxホストの物理的な分離を指す場合に使用します。
また、「組織」という言葉も使っています。SUSE Managerには「組織」という考え方があり、これはSUSE Manager Serverを最初にインストールするときに作成されるデフォルト組織の下に配置される個別の管理環境のことを指します。組織には1つの親（LDAP「組織」など）に多数の子（入れ子のないフラットな組織単位に制限されたLDAP「組織単位」など）が配置されています。 「###」### 「###」###SUSE Managerの組織には通常、Web UIからの管理が必要な個別の資格情報があります。SUSE Managerが管理するLinuxホストは単一の組織に登録されて、そこからしか表示することができません。これらの用語の意味を念頭に置きながらこのドキュメントを読み進めてください。
1.2 サンプルシナリオ #
Chameleon Corporationは世界最大の爬虫類・両生類専門ペットショップで、イエメンに本社を構えています。5か国でLizardsRUsやUnVeiledInc、Chameleo-ramaという名前の店舗を1500店以上展開しています。
同社にはLinuxホストのパッチとセキュリティ更新プログラムの管理について以下のような要件があります。コンプライアンスの制限により、同社のパッチライフサイクル（タイミングと配信）は自社のセキュリティポリシー、ホストの環境/ランドスケープ、および将来の管理ニーズをベースにしています。
要件の概要は以下のとおりです。
公開されているセキュリティポリシーでは、利用可能な最新の更新プログラム、バグ修正、機能強化を四半期ごとにすべてのLinuxシステムに適用するよう定められています。第一四半期が1月1日～3月31日、第二四半期が4月1日～6月30日、第三四半期が7月1日～9月30日、第四四半期が10月1日～12月31日となっています。###### ############### ############### ############### #########
公開されているセキュリティポリシーでは、パッチがリリースされてから1か月以内に「重要な」セキュリティ更新プログラム（CVSSスコアが7以上）をすべてのLinuxシステムに適用することも定められています。「###」 ###これにより、既存のパッチロールアウトと重なる可能性がある2つ目のスケジュールが発生します。
同社には、コーポレート、ストア、NPEという3つの異なるホスト環境があります。これらのホスト環境はSUSE Manager組織を使って区切られています。各SUSE Manager組織では、信頼に基づいてデフォルトのSUSE Manager組織のソフトウェアチャネルを見ることができますが、管理対象ホストは当然のことながら環境によってグループ化および管理されます。
各環境には少なくともDEV、UAT、PRODという3つのランドスケープがあります。一部の環境（SITやDITなど）には他のランドスケープもありますが、それらはさきほど説明したランドスケープと同様の方法で管理されます。パッチライフサイクルプロモーションとは、必要に応じてパッチを追加のステージへと移動させることです。
### 「###」 ロールアウトからパッチ（カーネル更新プログラムなど）を削除する必要があることも多いため、パッチ例外プロセスが用意されています。一部のホストには、特定のカーネルバージョンに依存するハードウェアドライバーやサードパーティソフトウェアがある場合もあります。この例外プロセスはケースに応じて適切に対処されます。
ここまでの話をまとめると、3つのSUSE Manager組織の3つ（またはそれ以上）のランドスケープで2つのパッチスケジュールが必要であることがわかります。また、コンプライアンスを確保するために、ロールアウトできない（例外）ものの追跡や修復、再導入が必要なパッチの保存場所に対処する方法も必要です。
SUSE Managerではこのような複雑さにも適切に対処して、こうした要件にも柔軟に対応できるように設定できます。いくつかのファセットを使って自動化を適用することもできます。また、公開されている企業ポリシーを満たす、パッチを一貫性のある形で配信できる手順を作成できます。
1.3 機能 #
このドキュメントでは、SUSE Manager環境を設定および構成して、以下のよくリクエストされることのある機能を企業で実現する方法について説明します。
四半期（または任意の期間）ごとのパッチ作成とアーカイブの自動化
多数のランドスケープと環境における、一貫性のあるパッチのプロモーションと配信
パッチサイクルから除外する必要があるパッチに対処するための例外プロセス
パッチ履歴セットを使った環境の作成
導入から廃止までホストチャネルサブスクリプションを操作する必要性の最小化
カスタムの子チャンネルを使ったサービスパックの移行のサポート
ランドスケープ（DEVとPRODまたはサンドボックス、DEV、QA、UAT、PRE-PROD、PRODなど）の増減や配信頻度の増減など、要件の変更に合わせてこうした機能の多くをカスタマイズできます。これらを念頭に置きながらこのドキュメントを読み進めてください。SUSE Managerは非常に柔軟性が高い製品であり、これまで多くのお客様が強固なシステムとパッチ管理フレームワークを構築および導入するのをサポートしてきました。貴社の要件はこのドキュメントに記載されているものとは異なるかもしれませんが、SUSE Managerの高い柔軟性によって貴社の現行のニーズや変化するニーズにも対応することができます。
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の設定について説明します。最初に、要件を満たすために用意するアーキテクチャ（およびコンポーネント）を説明してから、実際にそれを作成するステップへと移ります。このガイドの各コンポーネントは、これから説明する特定のシナリオに対する包括的なソリューションを実現するためにお互いに組み合わせて使用されますが、貴社独自のソリューション要件に合わせて個別に使用しても構いません。
2 導入 #
まず、SUSE Managerを設定して、パッチライフサイクル管理に役立ついくつかの手順、プロセス、ツール（スクリプト）を作成する必要があります。また、使用するSUSE Linux Enterprise Serverバージョン用に、SUSEが提供する更新プログラムチャネルからパッチアーカイブチャネルを作成（できれば自動作成）します。 「###」 ###「###」 ###これらのパッチアーカイブがパッチプロモーションのソースになりますが、過去にロールアウトされたパッチセットに基づいてテスト環境を設定するためのソースにもなります。たとえば、これまでのパッチセットがすべて適用されたホストがあるラボを作成するなど、エラー状態のトラブルシューティングに使うことができます。また、タイムスタンプが付いたパッチセットによって定義されたコンプライアンスについてもわかりやすい形で説明、および視覚化できます。
ロールアウトが決定した際に更新プログラムを取得する一連のソフトウェアチャネルも作成する必要があります。### 「###」 各ランドスケープでは、過去に検証済みのランドスケープからのみ更新プログラムを取得する必要があります。つまり、まずはじめにDEVに配置されて、DEVのマシン上でテストされます。その後、QAに移動してそこでもテストされます。そして最後にPRODに移動します。四半期ごとにこのプロセスが行われ、例外が発生した場合にはそれに対処します。あらゆる例外を修復し、できるだけ早くパッチを再導入してコンプライアンス状況を把握するための一貫性のある目標が設定された、確立された別のプロセスによってすべての例外を追跡します。
四半期よりも高い頻度でデプロイが必要な、重大なセキュリティパッチのリリースによって四半期ごとのロールアウトに割り込みが入ることもあります。 「###」 ###この追加スケジュールに対処するために、重大なパッチを追跡してロールアウトする別のチャネルを作成します。重大なパッチとみなされるのは、CVSSスコアが7.1以上のCVE、または企業セキュリティチームによって必須とされているパッチです。現在、以下の2つの異なる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）という2つの異なる環境を管理する必要があります。SUSE Manager組織を個別に作成することで、システム管理者が自分が管理するホストだけを見られるようにしています。各SUSE Manager組織には、パッチのテスト/プロモーションに使う3つのランドスケープ（DEV、QA、およびPROD）があります。
それぞれのSUSE Manager組織（各環境）とランドスケープでアクティベーションキーとブートストラップを作成することで、ほとんどの場合ホストを適切な固定ロールに登録することができます。たとえば、あるブートストラップスクリプトでSUSE Linux Enterprise Server 11 SP3（64ビット）のDEVホストを適切な組織に登録し、今後の操作が不要な適切なベースと子チャネルを追加するとします。この場合は自動化が推奨されます。さきほど説明したとおり、スクリプトやスケジュール設定したジョブを使うことで、ソリューションを大幅に強化して管理スタッフに安心感を与えることができます。
2.1 アーキテクチャ #
アーキテクチャとチャネルの概要は以下のとおりです。
ここに一覧表示されているすべてのベースチャネルは、SUSEベンダーチャネルのクローンツリーにできるため、名前にプレフィックスが含まれています。これは、この後のチャネル作成セクションで説明するサービスパックの移行をわかりやすくするための措置です。
SUSE Manager組織
デフォルト（メイン） - 1
32ビットアーカイブチャンネル（パブリック）
Q2 - 06-30-2015 - SLES 11 SP3 Updates for i586
Q3 - 09-30-2015 - SLES 11 SP3 Updates for i586
64ビットアーカイブチャンネル（パブリック）
Q2 - 06-30-2015 - SLES 11 SP3 Updates for x86_64
Q3 - 09-30-2015 - SLES 11 SP3 Updates for x86_64
Q2 - 06-30-2015 - SLES 12 Updates for x86_64
Q3 - 09-30-2015 - SLES 12 Updates for x86_64
SUSEベースチャネル内のクローンセットまたは子チャネル
ベース：SLES 11 SP3 Pool for i586
DEV - Current Patch Set - SLES 11 SP3 Updates for i586
QA - Current Patch Set - SLES 11 SP3 Updates for i586
PROD - Current Patch Set - SLES 11 SP3 Updates for i586
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 11 SP3 i586
Security ASAP Exceptions - SLES 11 SP3 i586
ベース：SLES 11 SP3 Pool for x86_64
DEV - Current Patch Set - SLES 11 SP3 Updates for x86_64
QA - Current Patch Set - SLES 11 SP3 Updates for x86_64
PROD - Current Patch Set - SLES 11 SP3 Updates for x86_64
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 11 SP3 x86_64
Security ASAP Exceptions - SLES 11 SP3 x86_64
ベース：SLES 12 SP3 Pool for x86_64
DEV - Current Patch Set - SLES 12 Updates for x86_64
QA - Current Patch Set - SLES 12 Updates for x86_64
PROD - Current Patch Set - SLES 12 Updates for x86_64
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 12 x86_64
Security ASAP Exceptions - SLES 12 x86_64
パッチ例外チャネル（上記のとおり）
ベースごとのチャネル - 各更新プログラムチャネルに1つのチャネル： 「###」###
例：
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 11 SP3 i586
Security ASAP Exceptions - SLES 11 SP3 i586
コーポレート（CORP） - 2
パブリックチャネルがここに表示される
プライベートチャネルは組織ごとに共有可能
ストア（STORE） - 3
パブリックチャネルがここに表示される
プライベートチャネルは組織ごとに共有可能
2.2 自動化とプロセスの設計 #
自動化には、アーカイブチャネルのチャネルクローンの自動作成が含まれます。特定の企業のユースケースや製品の使い方にも対応できるように、いくつかのスクリプト（cronとBash）と構成ファイルを組み合わせて使用します。アーカイブ作成は以下のカスタムcronジョブによってトリガーします。日付基準によって正確な設定を特定します。たとえば、四半期ごとのスケジュールを、特定の四半期の開始日または終了日に基づいて実装できます。トリガーする時間を四半期末にする場合、1か月が30日の3番目と9番目の月（3月と9月）と、1か月が31日の6番目と12番目の月（6月と12月）を考慮に入れる必要があります。### ###### ###### ###### ###これに対応するには、以下のような2つのcrontabエントリが必要です（cron構文）：
0 0 30 6,9 * /path/to/archive-create-script
00 0 31 3,12 * /path/to/archive-create-script
四半期の開始日を月の最初の日にする場合は、以下のようなcrontabエントリが1つだけ必要です。### ###
0 0 1 1,4,7,10 * /path/to/archive-create-script
### 「###」 実際のarchive-create-scriptスクリプトでは、スクリプトが実行される四半期を判断するためのロジックと、SUSE Managerチャネルのクローン作成用の正しい構文を提供するフォーマットロジックなどが必要です。スクリプトは、企業の選択に基づいて、アーカイブのフルセットを作成するために各アーキテクチャとSUSE Linux Enterprise Serverバージョンでも実行する必要があります。パッチプロモーションプロセスを作成することで、管理者はパッチセットを特定のランドスケープに移動するタイミング、そして同様に重要な移動元を正確かつ明示的に定義することができます。SUSE Managerで公開されているXMLRPC APIを活用したスクリプトを使うと最も簡単にこれを行うことができます。このAPIにはmergePackagesとmergeErrataと呼ばれるsoftwareChannelメソッドが含まれています。 「###」 ###「###」 ###「###」###ソースチャネルとターゲットチャネルを使ってこれら2つのメソッドを呼び出して、片方のチャネルから素早くコンテンツを取り出してもう一方のチャネルに差分をマージすることができます。
最後のプロセスではプロモーションプロセスからパッチを削除して、追跡用に保存するためのワークフローを定義します。例外は修復されるため、これらのパッチ例外は後でパッチロールアウトカレンダーに再導入できます。パッチを削除する例外プロセスの他に、緊急対応としてパッチを追加する似たようなプロセスがあります。
緊急パッチは最新のSUSE更新プログラムチャネルでほぼ常に利用できますが、アーカイブチャネルにはまだ導入されていない場合があります。四半期ごとのアーカイブチャネル作成ジョブがトリガーされると、利用可能なパッチがアーカイブセットに含まれます。しかし、それ以外のタイミングでは、パッチリリース前に発生するか、この最新のパッチを含む新しいアーカイブが作成されるまで最大で3か月かかる場合があります。そのため、パッチを検索してターゲットチャネルにコピーする方法を用意する必要があります。この方法を用意することで、SUSEが重大なパッチをリリースした場合に対処しますが、四半期が始まるまでアーカイブチャネルにはコピーが作成されません。
こうした緊急パッチをコピーしても、アーカイブチャネルの通常のデプロイと作成には影響しません。次回のアーカイブチャンネル作成にもこのパッチが含まれ、重複するパッチがある（後で同じパッチをマージする場合）緊急パッチチャネルを使っても、すでにそのパッチをインストールしてるシステムと競合が起きることはありません。
詳細な説明については後述する2.4項 「例外チャネルとエスカレーションチャネル」を参照してください。
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 Toolsチャネルと呼ばれる、SUSE Manager Clientパッケージ用のチャネル、およびSUSE Linux Enterprise Server 11 SP3 Updates for x86_64と呼ばれる更新プログラムチャネルを含む子チャネルがあります。
管理対象ホストがサブスクライブする通常のチャネルセットには親チャネル（プール）、SUSE ManagerToolsチャネル、および更新プログラムチャネルが少なくとも1つずつあります。SUSE Linux Enterprise Server 11 SP2など一部のケースでは、SUSE Linux Enterprise Server 11 SP1 Pool、SP1 Updatesチャネル、SP2 Coreチャネル、SP2 Updates、SP2 Extension Store、およびSP2 SUSE Manager Toolsチャネルが含まれます。
SUSE Linux Enterprise ServerのSP1とSP2はいずれもLTSSフェーズに入っているため、SUSEで非LTSS更新プログラムが作成されることはありません。つまり、企業にSP1ホストやSP2ホストがあり、追加のパッチとサポートを利用する場合は、LTSSを購入してLTSS Updatesチャネルを使用する必要があります。詳細についてはhttp://www.suse.com/lifecycleをご覧ください。
こちらの画像はパッチプロモーションプロセスを説明したものです。
2.4 例外チャネルとエスカレーションチャネル #
さまざまな理由により、デプロイメントサイクルでパッチを延期したり削除したりする場合があります。パッチがシステムの安定性に問題をもたらしたり、現在または以前のランドスケープのテストサイクルを通過していなかったり、パッチサイクル内でパッチをデプロイしない理由はさまざまです。その一方で、スケジュールを前倒して、（セキュリティの脆弱性や、悪影響のあるバグを修正する）重要なパッチをデプロイする場合もあります。こうしたパッチは重要なものであることから、次の四半期のパッチサイクルを待たずにできるだけ早くテストとデプロイを行う必要があります。
このような例外的なパッチの定期的な削除や追加を行うには、プロセスを作成して適切にパッチを追跡する必要があります。これらの例外を追跡する一方で、保管、説明、報告のために専用のチャネルコンテナにコピーします。
これらのチャネルは、パッチ例外に対応するSUSE Linux Enterprise Serverバージョンのアーカイブベースチャネル内、またはクローンされたベースチャネル内で作成できます（推奨）。
パッチを除外するプロセスでは、まずパッチ（および関連するパッケージ）を例外チャネルにコピーした後、現在のデプロイランドスケープからパッチ（および関連するパッケージ）を削除します。必要に応じて直近の四半期のアーカイブチャネルからパッチを削除することもできますが、パッチは今後の四半期のアーカイブにも含まれることを認識しておくことが重要です。SUSE更新プログラムチャネルからパッチを削除したくなるかもしれませんが、多くの場合コンプライアンス上の手違いや誤報告につながります。最初に例外の理由を追跡して解決しておいた方がはるかにましです。こうすることで、パッチをパッチデプロイワークフローに再導入して、パッチの修正対象である潜在的なセキュリティ問題やコードの欠陥を修復することができます。
2.4.1 セキュリティエスカレーションチャネルとプロセスの定義 #
セキュリティパッチを追加するプロセスはパッチを除外するプロセスと似ています。パッチが作成されているもののプロモーションサイクルでまだ使用されていない場合は、パッチをSUSE更新プログラムチャネルか最新のアーカイブからセキュリティ例外チャネルにコピーする必要がある点が、パッチ除外プロセスとの主な違いです。新しい重大なセキュリティパッチがロールアウトフェーズの途中（すでに直近の四半期のパッチをプロモーションしていたところにこの新しいパッチが来た）でリリースされた場合、この新しいパッチはまだアーカイブに表示されていない可能性があります。
この新しいパッチを通常のパッチセットと同じようにランドスケープにプロモーションしてテストする必要がある場合は、必要に応じて任意のステージに直接コピーできます。このセキュリティパッチを最初のランドスケープ（DEV - Currentなど）にコピーし、通常のデプロイ-テスト-プロモーションサイクルに従って本番環境に適用します。パッチの重要度に応じて、テストの通常スケジュールを早めるか、稀なケースですが、リスクが許容可能なものと想定してテストをスキップします。
2.5 コンポーネント #
SUSE Manager 2.1を使って高度なパッチライフサイクル管理を実現するために作成するものは以下のとおりです。
チャネル#
アーカイブチャネル
最新の更新プログラムチャネル
例外チャネル（Patch ExcludeまたはSecurity-ASAP）
オプションのSP-Migrationクローンセット
アクティベーションキー/ブートストラップ#
組織ごと/SLESバージョンごとのアクティベーションキー
組織ごと/SLESバージョンごとの登録ブートストラップ
スクリプト#
アーカイブ作成スクリプト
アーカイブソースリスト制御ファイル
マージツールPythonスクリプト
crontabエントリ/自動化#
四半期ごと（またはその他の頻度）でのアーカイブ作成呼び出し
2.6 チャネル #
さきほどのアーキテクチャのセクションで説明したとおり、パッチプロモーションプロセスをサポートするために複数のカスタムチャネルを作成します。これらのチャネルには（SUSE更新プログラムチャネルのクローンとして作成された）アーカイブと例外パッチが格納されます。各ランドスケープで、プロモーションされたパッチを保持するためのカスタムチャネルを作成します。これらのチャネルには、各サイクルでプロモーションされるパッチが徐々に累積されていきます。
たとえば、第一四半期（Q1）にはアーカイブチャネルに159個のパッチがあり、これらがSUSE Linux Enterprise Server 11 SP4のDEV更新プログラムチャネルにマージされたとします。SUSEでは継続的にパッチをリリースするため、次の四半期（たとえば第二四半期）のアーカイブが作成されると、第一四半期のすべてのパッチとは別に第二四半期の130個のパッチも含まれるため、パッチの総数は289個になります。マージ機能によって130個の新しいパッチ（および関連するパッケージ）が取得され、次のパッチサイクル中にDEV更新プログラムチャンネルに追加されます。
新しい各パッチサイクルは特定のランドスケープの最新の更新プログラムチャネルにある利用可能なパッチを更新します。 「###」 ###こうすることで、それ以降の各パッチプロモーションで新しい更新プログラムが追加されて、チャネルをサブスクライブしているホストに適用することができます。
例外チャネルは、個別のパッチを管理し、それらのパッチをいずれかのランドスケープ更新プログラムチャネル、またはアーカイブチャネルからコピーすることで設定します。パッチを例外チャネルにコピーしたら、更新プログラムチャネルまたはアーカイブから削除できます。
2.6.1 チャネルの作成 #
アーカイブチャネル：#
カスタムチャネルはSUSE Managerで、新規の何もコンテンツがない空のチャネル、またはクローンとして作成されます。「###」###「###」###技術的にはクローンされたチャネルを空のものとして作成することもできますが、今回のケースでは参照するSUSE更新プログラムチャネル、パッチ、およびパッケージから取得したコンテンツを含むアーカイブチャネルを作成します。各アーカイブチャネルは空のベースチャネル内に配置します。ベースチャネルはIA-32やx86_64、s390x、PPCなど、SUSE Managerが管理するプロセッサーアーキテクチャごとに作成します。SUSE Linux Enterprise Serverのさまざまなバージョンに対応する複数のアーカイブをベースチャネルに配置することもできますが、これらはすべて同じプロセッサーアーキテクチャになります。
ベースアーカイブチャネルを作成する手順は以下のとおりです。
SUSE Managerが管理するホストで使用するプロセッサーアーキテクチャごとに、32-bit Archives Channel と64-bit Archives Channelという名前の空チャネルを作成します。「###」 ###「###」###
Web UIでChannelsをクリックしたらサブメニューManage Software Channelsをクリックして、その後+Create Channelをクリックします。 「###」### 「###」 ### 「###」###
チャネルラベルはarchitecture-patch-archives-channelという形式にする必要があります。たとえば、64ビットチャネルラベルの場合はx86_64-patch-archives-channelにします。「###」###「###」###
重要: チャネルへのラベル付けこれらのチャネルに適切にラベル付けしないと、（修正しない場合）サンプルのアーカイブスクリプトが正しく動作しません。SUSE Managerではチャネルのラベルが厳密に評価され、すべて小文字にして、先頭を数字ではなく文字にし、スペースを使用しないなどさまざまなルールがあります。「###」 ###
先頭がx86_64のラベルを作成するこの例では、32ビットチャネルがi586かそれに類似するものと想定しています。 「###」 ###「###」 ###
これらのアーカイブチャネル自体が親チャネルであるため、これらのチャネルの親チャネルは存在しません。 「###」###「###」 ###
64ビットならx86_64、32ビットならIA-32など、チャネルに対して適切なアーキテクチャを選択してください。
各チャネルで「Public」ラジオボタンを選択して、すべての組織で表示されるようにします。
デプロイしたSUSE Linux Enterprise Serverの各アーキテクチャタイプで同じ手順を繰り返します。
クローンのアーカイブチャネルを作成します。
使用している各SUSE Linux Enterprise Serverバージョンでクローンチャンネルを作成します。
Web UIでChannelsをクリックしたらサブメニューManage Software Channelsをクリックして、その後Clone Channelをクリックします。 「###」### 「###」 ### 「###」###
ソースとしてアーカイブを作成するSUSE Linux Enterprise ServerバージョンのSUSE「Updates」チャネルを選択します。
すべてのコンテンツ/パッチでこのラジオボタンを選択してください。
Q3 - 09-30-2015 - Archive of SLES 11 SP3 for x86_64など、日時とアーカイブの内容がわかるようにチャネルに適切な名前をつけます。 「###」###
たとえば、以下のように適切な構文でラベルを作成します。
q3-09-30-2015-archive-sles11sp3-x86_64
重要：適切なベースアーカイブチャネルを選択してクローンを含めるようにしてください。
SummaryフィールドとDescriptionフィールドにチャネルの適切な説明を入力します。
完了したらCreate Channelをクリックします。 「###」 ###
画面を下にスクロールして「Public」ラジオボタンを選択したら、Update Channelをクリックします。 「###」###
各アーキテクチャのSUSE Linux Enterprise Serverバージョンで同じ手順を繰り返します。
省略可：spacewalk-clone-by-dateを使って、過去のものからアーカイブチャネルを作成します。
spacewalk-clone-by-dateユーティリティで使えるサンプルのソースファイルについては付録を参照してください。この構成ファイルは、チャネルのコンテンツをフィルタリングする特定の日付範囲が指定されたクローンチャネルを作成するために使用できます。
このユーティリティは以下の構文を使って呼び出します。
spacewalk-clone-by-date -c "config file"
過去の日付がある各アーカイブチャネルでこの手順を繰り返して、適切な日付とチャネルソース/ターゲット名に合うように構成ファイルを修正してください。
2.6.1.1 更新プログラムチャネルと例外チャネルを使ったサービスパックの移行サポート #
サービスパック移行機能を活用する際に、一貫性のある想定通りの動作を可能にするチャネルセットの管理方法として一般的に受け入れられているものがいくつかあります。この機能は各ホストのソフトウェアタブにあります。この機能を使うことで、ワンクリックで特定のホストのサービスパックを更新できます。このドキュメントで説明しているパッチライフサイクル手法を使うと、サービスパック移行機能利用時にいくつかの課題に直面します。特定のホストを選んでサービスパックの移行を実行すると、移行操作のためにサブスクライブされる必須の子チャネルがUIによって提示（表示）されます。 「###」###これら必須の子チャネル（UIではグレーアウトされています）には通常、SUSE Linux Enterprise Serverの特定のバージョン用の、SUSEが提供する更新プログラムチャネルが含まれています。
以下のスクリーンショットを参照してください。
こちらで説明しているパッチライフサイクルプロセスとサービスパック移行機能を使うためには、自社で使用しているSUSE Linux Enterprise Serverの製品バージョンの完全なクローンセットを作成するのが最適です。これはclone-treeと呼ばれることもあり、softwarechannel_clonetreeにあるものと同じ名前のspacecmdコマンドを使用することで簡単に作成できます。 ############
完全なクローンツリーにはベース/親チャネル（通常はプールと呼ばれる）、および現在その下にあるすべての子チャネルが含まれます。たとえば、SUSE Linux Enterprise Server 11 SP3 Pool x86_64チャネルをソースとして使用している場合、clone-treeコマンドに独自のプレフィックスを追加することで、プールとすべての子のコピーを作成してすべてのチャネルの名前とラベルの先頭にプレフィックスを追加します。
以下は、元のSUSE Linux Enterprise Server 11 SP3 x86_64チャネルと、その横にプレフィックスバージョンChameleon_Co-が付いたクローンツリーの画像です。「###」 ###
### ### spacecmdシェル内からコマンドを呼び出して、直接、または対話形式でソースとプレフィックスの情報を提供することで、spacecmd softwarechannel_clonetreeコマンドを直接呼び出すことができます。
例：
spacecmd -u <SMadmin> -- softwarechannel_clonetree -s sles11-sp3-pool-x86_64 -p "my_company-"
<SMadmin>を実際のSUSE Manager webUI管理者ユーザー名と置き換えてください。
このコマンドを実行すると、先頭にmy_companyと付いたSUSE Linux Enterprise Server 11 SP3 x86_64チャネルの完全なセットが作成されます。 「###」###
SUSE Linux Enterprise Serverの各バージョンでこのプロセスを繰り返し、サービスパック移行機能を使用している場合は、SUSE Linux Enterprise Serverのターゲットバージョンとして自社で使用しているバージョンを選択し、ホストがあるランドスケープに適切な子チャネルを選択します（以下の画像を参照）：
その後、すべてのパッチ/パッケージを削除することで、クローンされた更新プログラムを修正してから、マージスクリプトプロセスを使って最新のパッチセットを必須の更新プログラムチャネルにマージします。 「###」 ###このようにしてサービスパックの移行を行うことができますが、現在プロモーションされているパッチセットはそのまま保持されます。それ以外の場合、サービスパック移行では常に必須更新プログラム子チャネルの最新パッケージに更新されます。「###」 ###
227個のパッケージがあるSUSE Linux Enterprise Server 11 SP4用第三四半期パッチアーカイブ、234個のパッケージがあるSP4用のSUSE更新プログラムチャネル、パッケージがないChameleon Corporation用のSP4更新プログラムチャネルを示した以下のスクリーンショットを見てみてください。
以降のセクションでは、カスタムの最新の更新プログラムチャネルの作成とマージスクリプトの使い方について説明します。 「###」###### 「###」 ### 「###」 ### 「###」 ###「###」 プロモーション済みパッチの独自セットを使ったサービスパック移行では、最新のパッチアーカイブを本番チャネルから更新プログラムチャネルにマージして移行作業に使用します。または、単純に更新プログラムチャネルを常に空にしておいて、最新更新プログラムチャネルを、選択したオプションの子チャネルに追加します。 「###」###
空の更新プログラムチャネルと、設定済みの最新の更新プログラムチャネルを使って、サービスパックの移行作業を想定通りに進めて、本番よりも新しいバージョンのパッケージがマシンに適用されないようにすることができます。「###」 ###「###」###「###」######「###」 カスタムの更新プログラムチャネルとマージスクリプトプロセスについては以降のセクションで詳しく説明します。
「###」更新プログラムチャネル：#
ここからは、ランドスケープに応じて、管理対象ホストがサブスクライブする最新の更新プログラムチャネルを作成します。 「###」###「たとえば、DEV - Current Updates - for SLES 11 SP3 x86_64やPROD - Current Updates - for SLES 12 x86_64という名前のチャネルを作成します。」### 「###」###各SUSE Linux Enterprise Serverバージョン用のランドスケープチャネルのフルセットが作成されますが、最初はどれも空です。新しいチャネルを作成したら、必要に応じてそのチャンネルのクローンを作成してタイピングの手間を減らします。「###」 ###「###」 ###
Manage Software Channelsサブメニューから+Create Channelをクリックします。 「###」 ###「###」###
いずれかのSUSE Linux Enterpriseプールチャネルでチャネルを作成するか、独自のクローンセットがある場合はそのプール内でチャネルを作成します。
チャネルを修正して「Public」にします。
残りのランドスケープにこの新しいチャネル（更新プログラムは含めない）をクローンします。それぞれ「Current Updates -」という名前にし、適切なランドスケーププレフィックスを付けます（「DEV -」、 「TEST - 」、「PROD - 」など）。「###」### 「###」### 「###」###「###」###
管理することになる各SUSE Linux Enterprise Serverバージョンにランドスケープのフルセットが作成されます。SUSE Linux Enterprise Server 11 SP1チャネルとSP2チャネルでは、2つのフルセット（2倍）、またはLTSSがある4つのフルセット（4倍）が作成されます。ただし、SP1とSP2の更新プログラムチャネルは更新されなくなっているため、現在は静的チャネルとしてサブスクライブすることができます（2.3項 「パッチプロモーションサイクル」のLTSSに関する注意事項を参照してください）。
「例外チャネル：」####
それでは、管理するSUSE Linux Enterprise Serverの各バージョンで例外チャネルを2つ作成しましょう。アーキテクチャ固有の混合チャネルを作成することができますが（アーカイブチャネルベースなど）、パッチ例外がどのディストリビューションのものかを管理するのは面倒な場合があります。異なるSUSE Linux Enterprise Serverバージョンのパッチ/パッケージを混在させた場合、パッチの管理、解決およびパッチワークフローにパッチを再導入するのが難しくなります。パッチに対応するSUSE Linux Enterprise Serverバージョンの例外チャネルにパッチを置いておく方がはるかに簡単です。次の手順に従ってPatch ExceptionチャネルとSecurity ASAP Exceptionチャネルを作成します。 「###」 ###「###」 ###
Manage Software Channelsサブメニューから+Create Channelをクリックします。 「###」 ###「###」###
いずれかのSUSE Linux Enterprise ServerプールチャネルでPatch Exceptions - DO NOT SUBSCRIBEチャンネルを作成するか、独自のクローンセットがある場合はそのプール内でチャネルを作成します。 「###」 ###このチャネルはランドスケープチャネルの隣に配置します。
チャネルを修正して「Public」にします。
上記の手順に従ってSecurity ASAP Exceptionチャネルを作成します。こちらもランドスケープチャネルとパッチ例外チャネルの隣に配置します。 「###」 ###
SUSE Linux Enterprise Server 11 SP1とSP2では次の点に注意が必要です。これらは同じSP1プールベースチャネルに配置されるため、各サービスパックには例外チャネルとセキュリティ例外チャネルがあります。
2.7 アクティベーションキー/ブートストラップ #
通常であれば、ホストがインストールされた特定のSUSE Linux Enterprise Serverバージョンに割り当てられたアクティベーションキーの作成が完了しているはずです。システムグループやさまざまな子チャネル、ソフトウェアパッケージなど、さまざまな特徴がキーに割り当てられている場合があります。既存のアクティベーションキーを修正してそれを再利用するか、今回の実装用に新しいキーを作成することができます。この例ではキーが新しいものと想定しています。
Systemsメニューの左側のパネルでActivation Keysサブメニューをクリックします。 「###」 ### 「###」 ###
右上にある+Create Keyをクリックします。 「###」 ###
この組織内でアクティベーションキーを作成します（必要に応じて別の組織にログインしてキーを作成してください）。必要に応じて適切な権限、ソフトウェアパッケージ、構成チャネルを割り当てます。
このキーを使って登録するランドスケープホストに応じてアクティベーションキーに名前を付けます。
例：
図 7: アクティベーションキーの作成を示したスクリーンショット #重要：「Child Channels」タブをクリックします。このキーを使用するランドスケープに応じて適切な最新の更新プログラムチャネルを割り当てることができます。
例：
図 8: 「Child Channels」タブのスクリーンショット #適切なSUSE Manager Toolsチャネルと必要な他のチャネルを選択して、対象のSUSE Linux Enterprise Serverバージョンの要件を入力します。
Security ASAP Exceptionsチャネルがアクティブな子チャネルとして選択され、Patch Exceptions (DO NOT SUBSCRIBE)チャネルが選択されていない点に注目してください。Patch Exceptionsチャネルにコピーされたすべてのパッチ/パッケージはホストで非表示のままになる一方、Security ASAP Exceptionsチャネルにコピーされたパッチ/パッケージは常に即座にホストに表示されます。
アクティベーションキーはブートストラップスクリプトによって呼び出されます。通常は登録ブートストラップスクリプトとアクティベーションキーの間に1対1の関係があります。アクティベーションキーを新たに作成するか、ランドスケープ固有の最新の更新プログラムチャネルを指すように既存のキーを修正した場合、アクティベーションキーを呼び出すブートストラップスクリプトを用意する必要があります。 「###」 ###
すべての新規ホストでこれらのブートストラップを使って登録し、SUSE Managerの管理対象になります。ホストが適切なランドスケープ更新プログラムチャネルに割り当てられ、各パッチサイクルで新しい更新プログラムがプロモーションされるたびにそれを受信するため、ホストでチャネル割り当てを変更する必要がないというのが主なメリットの1つです。プロモーションについてはセクション2.8項 「スクリプト」で説明します。
2.8 スクリプト #
パッチ/パッケージマージスクリプト：#
### 「###」 パッチ/パッケージマージスクリプトを使うと、あるチャネルから別のチャネルにパッチ（および関連するパッケージ）を プロモーションできます。まず、アーカイブチャネルからDEVなどの最初のステージ（ランドスケープ）にコンテンツをマージするためにこのスクリプトを使用します。その後、コンテンツが最後のステージに到達するまで、ステージに順番にコンテンツをプロモートするために使用します。このプロセスは各SUSE Linux Enterprise Serverバージョン（11 SP1やSP2など）と各企業環境（STOREやCORPなど）で繰り返されます。
最後に、各パッチカレンダーサイクル（四半期ごと/毎月など）でプロセス全体が繰り返されます。
チャネルアーカイブ作成スクリプト/チャネルアーカイブソースリスト構成ファイル：#
このスクリプトと、関連するソースリスト構成ファイルは手動、またはcrontabエントリで呼び出します。 「###」 ###このスクリプトではソースリストファイルを使って、アーカイブを作成するSUSE Linux Enterprise Serverのバージョンとアーキテクチャを判断します。さきほど説明したとおり、さまざまなSUSE Linux Enterprise Server更新プログラムチャネルの特定の時点のクローンとしてアーカイブチャネルは作成されます。
適切なアーカイブチャネルを作成するにはソースファイルに行を追加します。各行には3つのフィールドがあります。1つ目がアーキテクチャ、2つ目がソースチャネル、そして3つ目がターゲットチャネルテキストです。スクリプトはソースリストを解析してアーキテクチャごとにアーカイブのターゲット親チャネルを作成してからターゲットチャネルやラベルなどを作成します。
このスクリプトはソースリストの各エントリでspacecmdの関数であるsoftwarechannel_cloneとsoftwarechannel_setorgaccessを呼び出します。 ###### ### ###### ###現在の四半期を計算し、アーカイブを作成してこれらのアーカイブを誰でも表示できるようにします。スクリプト全体については付録を参照してください。
2.9 crontabエントリ/自動化 #
アーカイブ作成スクリプト用のスケジュールベースのトリガー（四半期末）#
特定の月の末日（四半期開始の前日）に四半期を作成するのか、月の初日（前の四半期が終了してから1日後）に作成するのかを決める必要があります。特定のSLESバージョンのSUSE更新プログラムチャネルのクローンを作成することでアーカイブチャネルが作成されるため、決定はコンテンツにも影響します。
四半期間で整合性が取れるため、どちらの方法でも構いません。cron構文を説明するために、これら2つの方法より難しい使い方をあえてお見せします。四半期末にアーカイブスクリプトを呼び出すにはどうすればよいでしょうか。1か月が30日の月（6月と9月）と31日の月（3月と12月）の両方に対応する2つのcronエントリが必要になるため、これを実現するのは簡単ではありません。### ###### ###
crontabエントリはアーカイブ作成スクリプトを指し、3月、6月、9月、および12月に実行されます。cronエントリは以下のようになります。
0 0 30 6,9 * /path/to/the/archive/script
0 0 31 3,12 * /path/to/the/archive/script
パスは実際のarchive-channel-create-script.sh（または類似するもの）を指します。これを/usr/sbin/に配置して、実行可能ファイルにする必要があります（chmod +x）。
このスクリプトはBashシェルスクリプト内からspacecmdコマンドを呼び出す点も非常に重要ですので覚えておいてください。 ### ###spacecmd自体はPythonをベースにした呼び出し可能なシェルであり、シェル内や、シェル外から仲介コマンドインタープリターとしてさまざまなコマンドが利用できます。
spacecmdを呼び出すと、呼び出したユーザーのホームディレクトリに.spacecmdディレクトリが作成されます。.spacecmdディレクトリには、spacecmdの実行時にプロンプトが表示されなくなるようにするための資格情報セットを保存できる構成ファイルがあります。このファイルに資格情報を保存すると、cronジョブを実行しても認証資格情報が渡されるのを待つために停止することがなくなります。
crontabエントリはアーカイブ作成スクリプトを指し、3月、6月、9月、および12月に実行されます。cronエントリは以下のようになります。
[spacecmd]
server=localhost
username=admin
password=suse1234
nossl=0
これらの資格情報を保存することで、ユーザー名やパスワードを渡さずにSUSE Managerのルートユーザーがspacecmd操作を実行できるようになり、ある程度時間が経過しても失敗しない、アーカイブ作成用cronジョブを実行できます。### ###
3 ワークフローサンプル #
このガイドでは、SUSE Managerを活用して以下のメリットを実現するパッチライフサイクル管理のアプローチについて説明します。
パッチアーカイブチャネルの自動作成：
これらのチャネルは四半期ごと（またはそれ以上の頻度）で作成することができ、パッチの履歴セットに基づいて組織がテスト環境を作成することを可能とします（たとえば、2つ前の四半期の利用可能なパッチからラボを作成するなど）。
最新の更新プログラムチャネルの静的セットを活用することで、ホストのサブスクリプションを変更する必要がなくなります。 「###」###
API/スクリプトを使って更新プログラムをパッチアーカイブからサブスクライブしているホストチャネルにマージすることで、常にチャネルのクローン作成と再クローン作成を実行してホストのサブスクリプションを修正する必要がなくなります。 「###」 ###
複数のランドスケープがある環境では、プロモーションプロセスを使って、パッチセットのテスト/検証中に各フェーズで更新プログラムをマージできます。
パッチロールアウトから除外する必要があるパッチの例外処理：
パッチ例外チャネルと、そのチャネルのパッチ/パッケージをコピー（その後、更新プログラムチャネルから削除）するプロセスを作成することで、パッチ例外を追跡できます。 「###」 ###このチャネルはすべてのホストチャネルサブスクリプションから除外して、すべてのパッチ/パッケージコンテンツを表示またはインストールできるようにする必要があります。
パッチ例外プロセスを構築してすべての例外の修復を追跡し、増え続ける大量のパッチを将来的に管理する手間を省くようにする必要があります。 「###」###
高い優先度でロールアウトする必要があるパッチのセキュリティASAP例外処理：
（パッチ例外チャネルとは異なり）セキュリティASAP例外チャネルを必ずサブスクライブする必要があります。「###」###このチャネルをサブスクライブすることで、たとえば、重要とされるセキュリティパッチを通常のパッチスケジュール外でデプロイした場合など、予定外の方法で追加されたパッチ/パッケージをホストが取得できるようになります。このようなパッチは新しいアーカイブから、またはSUSE（ベンダー）更新プログラムチャネルから直接コピーできます。
3.1 プロセスワークフローのサンプル #
ここではパッチプロモーションと例外のプロセスの推奨ワークフローをいくつか説明します。特定の運用グループの既存のプロセスセットにより適合するようにサンプルプロセスを修正することができます。
ワークフロー1：パッチプロモーションプロセス#
パッチプロモーションプロセスは以下のサンプルステップに従います。
| アクション | プロセス | 説明 |
|---|---|---|
| レビュー | 既存のカレンダーを参照してパッチロールアウトの開始日を決定します。 | 通常は四半期の1日目が開始日になりますが、ロールアウトの頻度とあらかじめ決められた期間によって開始日は異なります。 |
| 選択 | パッチロールアウトの対象になるSUSE Manager組織と環境を指定します。 | このドキュメントのシナリオでは、CORP、STORE 、またはNPEのいずれかになり、SUSE Manager組織の使い方によっては、管理者が組織にログインしてホストを確認する必要があります。 |
| 選択 | パッチを適用するSUSE Linux Enterprise Serverバージョンを選択します。 | パッチプロモーションは各SUSE Linux Enterprise Serverバージョンで実行されます。各バージョンにはパッチがプロモートされるランドスケープチャネル（DEV、TEST、QA、 PRODなど）の独自のセットがあります。 |
| マージ | 最新のアーカイブを最初のランドスケープ（または選択したランドスケープ）にマージします。 | ### 「###」マージスクリプトユーティリティの使用：ソースチャネル（この場合はアーカイブ）とターゲットチャネル（シリーズを開始するDEV - Current）を選択します。 |
| デプロイ | 最新のランドスケープからサブスクライブしているホストにパッチをデプロイします。 | パッチがマージされると、最新のチャネルをサブスクライブしているホストのステータスに利用可能なパッチが表示されます。「###」 ###適切なパッチコマンドを発行してこれらのパッチをデプロイします。 |
| テスト | デプロイされている最新のパッチを受け取ったホストでテストを実施するか、評価を開始するよう適切なチーム/事業部門に連絡します。 | パッチがデプロイされたらテストやレビューを開始してパッチのデプロイが成功したかどうかを検証します。デプロイを成功に導くにはビジネスパートナーとの調整が必要です。 |
| 評価 | 前のマージ/デプロイの結果を評価して次のランドスケープに進みます。最後のランドスケープの場合はレポートが完了します。 | 最後のランドスケープまで、各ランドスケープでパッチセットのマージとデプロイを継続します。レポートの完了：すべてのホストのステータスがグリーンになります。「###」 ### |
ワークフロー2：パッチ例外プロセス#
パッチ例外プロセスでは以下のサンプルステップに従います。繰り返しになりますが、特定の運用グループの既存のプロセスセットにより適合するようにサンプルプロセスを修正することができます。
以下の表を確認してください。
| アクション | プロセス | 説明 |
|---|---|---|
| 指定 | パッチセットから削除する可能性がある、例外として指定するパッチを見つけます。 「###」 ### | SUSE Managerの検索ツールを使ってパッチを見つけるか、特定のアーカイブやランドスケープチャネルでパッチを見つけます。 |
| コピー | ### 「###」SUSE Managerのチャネル管理機能の使用：特定のSUSE Linux Enterprise Serverバージョンの例外チャネルを選択して、（前のステップの）ソースからそこに指定したパッチを追加します。 |
パッチのソース（チャネル）とパッチのターゲット（例外チャネル）が重要です。SUSE Linux Enterprise Serverバージョンごとにこのステップを繰り返す場合があります。パッチのソースになるものは以下のとおりです。
|
| 削除 | ### 「###」SUSE Managerのチャネル管理機能の使用：パッチを一覧表示して、前のステップで追加されたパッチを見つけます。「###」 ###追加されたパッチが見つかったら、現在のフェーズ（もしくは複数のフェーズ）からそれを削除します。 | パッチを見つけてランドスケープチャネルから削除することで、チャネルはサブスクライブしているホストにパッチを表示して適合性を報告することができます。 |
| 追跡 | チケットを送信するか、あらかじめ用意したプロセスを開始してこのパッチ例外を追跡します。 | 追跡の目的は、例外の修復の試みを把握することであり、これによってパッチをパッチデプロイサイクルに再導入することができます。 |
| 修復 | 例外を修復するための作業です。 | 特定の例外で修復を指定/作成したら、パッチをデプロイワークフローに再導入できます。 |
| 注 | 例外は単一のデプロイサイクルで終了する必要があります。次のアーカイブにもこの同じパッチが含まれるのですが、これは特に問題ありません。 | 例外は常に一時的な状態にする必要があります。パッチをロールアウトできない理由を修正するための作業を必ず行ってください。例外があるとコンプライアンスがリスクに晒されます。 |
ワークフロー3：セキュリティパッチASAPプロセス#
セキュリティ例外プロセスは前のパッチ例外プロセスとは異なり、通常、現在（進行中）のロールアウトの途中でパッチロールアウトサイクルにパッチが追加されます。よりわかりやすく説明するために、別のプロセステーブルとSUSE Managerインターフェースのスクリーンショットをいくつかここでお見せします。
以下の表を確認してください。
| アクション | プロセス | 説明 |
|---|---|---|
| 指定 | ### 「###」特定のランドスケープやパッチセットに追加する可能性がある、セキュリティ例外として指定するパッチを見つけます。 | SUSE Managerの検索ツールを使ってパッチを見つけるか、特定のSUSE Linux Enterprise Serverバージョンの特定の更新プログラムチャネルでパッチを見つけます。 |
| コピー | ### 「###」SUSE Managerのチャネル管理機能を使用し、特定のSUSE Linux Enterprise ServerバージョンのSecurity ASAP Exceptionチャネルを選択して、（前のステップのSUSE更新プログラムチャネル）ソースからそこに指定したパッチを追加します。 |
セキュリティパッチのソース（SUSE更新プログラムチャネル）とパッチのターゲット（Security Exceptions ASAPチャネル）が重要です。SLESバージョンごとにこのステップを繰り返す場合があります。パッチのソースになるものは以下のとおりです。
|
| デプロイ | セキュリティ例外パッチを選択したランドスケープからサブスクライブしているホストにデプロイします。 | セキュリティパッチがランドスケープチャネルに追加されると、「最新」のチャネルをサブスクライブしているホストのステータスにパッチが利用可能であることが表示されます。適切なパッチコマンドを発行してこれらのパッチをデプロイします。 |
| 追跡 | チケットを送信するか、あらかじめ用意したプロセスを開始することでこのセキュリティパッチ例外を追跡します。 | 追跡の目的は、セキュリティパッチ例外がデプロイされたことを把握するためです。このパッチは次回の四半期ごとの自動作成中に通常のアーカイブの一部になります。 |
| レポート | セキュリティ例外は通常、コンプライアンスの懸念に対応するために発生します。デプロイされると、コンプライアンス（監査）レポートを生成できます。 | セキュリティ例外は通常のスケジュールへのエスカレーションとして扱われます。セキュリティ例外は通常の処理として次のアーカイブに組み込まれて、デフォルトのスケジュールの一環としてデプロイされます。そして当然ながら、次の通常のロールアウトではこのパッチを含める必要はありません（すでにデプロイされているため）。 |
このスクリーンショットはSecurity ASAP Exceptionsチャネル、つまりSLES 11 SP1 x86_64バージョンにパッチを追加する機能を示したものです。
このスクリーンショットは特定のチャンネル（この場合はDEV - Current - SLES11-SP1-LTSS-Updates for x86_64）の一覧表示/削除機能を示したもので、パッチをチャネルから削除して、表示される状態にしたまま例外プロセスの一環としてデプロイするインターフェースです。 「###」###
4 付録 #
4.1 Spacewalk-Clone-By-Date構成ファイルのサンプル # #
このサンプルはテキストファイルとして保存されています。-cフラグを使ってspacewalk-clone-by-dateユーティリティと一緒に使用して、入力構成ファイルを指定します。
spacewalk-clone-by-date -c Q3-2015-sles11sp3-x86_64-archive.conf
このコードではベースチャネルソースsles11-sp3-pool-x86_64とターゲットベースチャネル（アーカイブ先）cc_patch_archives_channel_64bitを指定し、existing-parent-do-not-modify: trueディレクティブを使用します。これにより、1つのベースの子チャネルをまったく異なるベースチャネルにクローンするようユーティリティに指示します。実際のチャネル名がサンプルと異なっている場合があるため注意してください。チャネル名が異なっている場合は、貴社の環境で動作させるためにサンプルの修正が必要です。例：Q3-2015-sles11sp3-x86_64-archive.confの内容は次のとおりです。
{
"username":"SMadmin",
"to_date": "2015-09-30",
"skip_depsolve":false,
"security_only":false,
"use_update_date":false,
"no_errata_sync":false,
"dry_run":false,
"channels":[
{
"sles11-sp3-pool-x86_64": {
"label": "cc_patch_archives_channel_64bit",
"existing-parent-do-not-modify": true
},
"sles11-sp3-updates-x86_64": {
"label": "09_30_2015_q3_archive-sles11-sp3-updates-x86_64",
"name": "Q3-2015 Patch Archive - 09-30-2015 - SLES11-SP3-Updates for x86_64",
"summary": "Q3 - 2015 - Patch Archive Set (9-30-2015) - SUSE Linux Enterprise Server 11 SP3 x86_64",
"description": "Q3 - 2015 - Patch Archive Set (9-30-2015) - SUSE Linux Enterprise Server 11 SP3 x86_64"
}
}
]
}spacewalk-clone-by-dateユーティリティを使用する際は、作成後にチャネルパッチコンテンツを確認して、適切な終了日のパッチがチャネルに含まれていることを確認してください。間違った期間のパッチがチャネルに余計に含まれている場合がありますが、それらは手動で削除できます。
4.2 Pythonを使ったパッチ/パッケージマージスクリプトのサンプル #
このスクリプトには、MANAGER_URLで定義済みのSUSE ManagerサーバーURLセットがあります。 ######このスクリプトではSUSE Managerの管理者IDとパスワードが求められます。その後、ソースチャネルとターゲットチャネルを尋ねられます。チャンネルに間違いがないかを確認する画面が表示され、処理を続行してよいかを尋ねられます。肯定的な回答（Y）をすることで、スクリプトによってソースチャネルからターゲットチャネルにパッチとパッケージがマージされます。
#!/usr/bin/python
import xmlrpclib
import sys
import getpass
MANAGER_URL = "https://suma01.chameleoncorp.com/rpc/api"
MANAGER_LOGIN = raw_input("Please Enter the SUSE Manager Login Name: ")
MANAGER_PASSWORD = getpass.getpass("Please Enter the Password: ")
MERGE_SOURCE = raw_input("Enter the SOURCE channel label to Merge FROM: ")
MERGE_TARGET = raw_input("Enter the TARGET channel label to Merge INTO: ")
print("This tool is going to take all packages and errata from the SOURCE")
print("Channel : " + MERGE_SOURCE)
print("and merge it into the TARGET ")
print("Channel : " + MERGE_TARGET)
def query_yes_no(question, default="yes"):
"""Ask a yes/no question via raw_input() and return their answer.
"question" is a string that is presented to the user.
"default" is the presumed answer if the user just hits <Enter>.
It must be "yes" (the default), "no" or None (meaning
an answer is required of the user).
The "answer" return value is True for "yes" or False for "no".
"""
valid = {"yes": True, "y": True, "ye": True,
"no": False, "n": False}
if default is None:
prompt = " [y/n] "
elif default == "yes":
prompt = " [Y/n] "
elif default == "no":
prompt = " [y/N] "
else:
raise ValueError("invalid default answer: '%s'" % default)
while True:
sys.stdout.write(question + prompt)
choice = raw_input().lower()
if default is not None and choice == '':
return valid[default]
elif choice in valid:
return valid[choice]
else:
sys.stdout.write("Please respond with 'yes' or 'no' "
"(or 'y' or 'n').\n")
query_yes_no("Is this information correct?")
client = xmlrpclib.Server(MANAGER_URL, verbose=0)
key = client.auth.login(MANAGER_LOGIN, MANAGER_PASSWORD)
client.channel.software.mergePackages(key, MERGE_SOURCE, MERGE_TARGET)
client.channel.software.mergeErrata(key, MERGE_SOURCE, MERGE_TARGET)
client.auth.logout(key)4.3 アーカイブチャネル作成を自動化するためのcrontabエントリのサンプル #
以下は、四半期ごとにチャネルを作成するアーカイブチャネル作成スクリプトを実行するのに使用できるcronエントリのサンプルです。このサンプルには四半期末までに受信したすべてのパッチのクローンを作成する2つのエントリがあります。四半期末の最初にクローンを作成する場合はエントリが1つだけで問題ありませんが、その場合はアーカイブスクリプトの計算を修正するのを忘れないようにする必要があります。現在、以下のアーカイブチャネル作成スクリプトのサンプルでは、現在の日付を見ることで対象となる四半期を判断しています。第四四半期でこのスクリプトを実行すると、第四四半期のアーカイブであることを示すアーカイブが作成されます。### ###### ###
四半期末のcronエントリ：（6月と9月の月末が30日で、3月と12月の月末が31日の場合）：### ###### ###
0 0 30 6,9 * /path/to/the/archive/script
0 0 31 3,12 * /path/to/the/archive/script
4.4 SUSE Manager 2.1および3.0用のアーカイブチャネル作成サンプルスクリプト #
以下のスクリプトをアーカイブチャネルソースファイル（4.6項 「アーカイブチャネルソースリストファイルのサンプル」を参照）と一緒に使用して、SUSE更新プログラムチャネルの四半期ごとのアーカイブを作成します。このサンプルスクリプトはBashで書かれていますが、クローン作成を実行するためにspacecmdを呼び出し、新しいアーカイブをパブリック（他の組織からもアクセス可能）に設定します。 ### ###
スクリプトの実行にはしばらく時間がかかります。クローンコマンドはすぐに終了しますが、実際にクローンされたチャネルが利用できるようになり、org-accessコマンドがチャネルにアクセスして処理を完了するまでにはしばらく時間がかかります。### ###これを手動でテストする場合は手間と時間がかかります。スクリプトの通常のcrontab実行はしばらくすると終了します。
#!/bin/bash
####################################################################
# SUMA Archive Channel Creation Script - Called from Cron #
# #
# This script creates quarterly archives of SUSE Manager #
# channels from SUSE Updates channels. It takes a list #
# of source channels from the archive-sources.lst file #
# that should be located in the same directory as this #
# script. Each entry in that file will be used as a #
# source channel to create an archive for patches/updates #
# in the appropriate archive channel. #
# #
# REQUIRES: #
# 1. cron entries for each quarter : #
# e.g. 30th of months June and Sept. and 31st of months March #
# and December: #
# 0 0 30 6,9 * /path/to/this/script #
# 0 0 31 3,12 * /path/to/this/script #
# #
# 2. archive-sources.lst : #
# A list of the architecture, the source updates channel #
# for each distro and the suffix of the target channel #
# version and architecture (1 per line - no line-feed at EOF) #
# Example: #
# S390x,sles11-sp3-updates-s390x,SLES11-SP3-Updates for s390x #
# ppc64,sles11-sp4-updates-ppc64,SLES11-SP4-Updates for PPC #
# x86_64,sles11-sp3-updates-x86_64,SLES11-SP3-Updates for x86_64 #
# etc. #
# #
####################################################################
# #
# Created by - Jeff Price, SUSE Consulting - 2015 #
# #
####################################################################
## date strings
month=`date +%m`
year=`date +%Y`
fdate=`date +%m-%d-%Y`
## set quarter
if [ $month -le 3 ]
then
quar=1
elif [ $month -gt 3 ] && [ $month -lt 7 ]
then
quar=2
elif [ $month -gt 6 ] && [ $month -lt 10 ]
then
quar=3
elif [ $month -gt 9 ]
then
quar=4
fi
## Create archives using source list
while read line
do
arch=`echo "$line" | awk -F, '{print $1}'`
src_ch=`echo "$line" | awk -F, '{print $2}'`
trg_ch=`echo "$line" | awk -F, '{print $3}'`
## set archive channel
target_parent=$arch"-patch-archives-channel"
source_channel=$src_ch
target_channel_name="Q"$quar" "$year" - "$fdate" - Archive of "$trg_ch
target_summary="Q"$quar"-"$year" Archive Set "$trg_ch
target_channel_label="q"$quar"-"$year"-archive-"$src_ch
## Debug Output
echo "Architecture: " $arch
echo "Source Channel: "$src_ch
echo "Target Channel Archive Suffix: "$trg_ch
echo "Target Archive Parent Channel: "$target_parent
echo "Source Channel (again): "$source_channel
echo "Target Channel Name: "$target_channel_name
lctn=`echo $target_channel_name|tr '[:upper:]' '[:lower:]'`
echo "lowercase target name: "$lctn
echo "Target Channel Label: "$target_channel_label
echo "Target Channel Summary and Description: "$target_summary
/usr/bin/spacecmd -d -- softwarechannel_clone -s “‘$src_ch’” -n
“‘$target_channel_name’” -l “‘$target_channel_label’” -p “‘$target_parent’” - g
/usr/bin/spacecmd -d -- softwarechannel_setorgaccess
“‘$target_channel_label’” -e
done < ./archive-sources.lst4.5 SUSE Manager 3.1および3.2用のアーカイブチャネル作成サンプルスクリプト #
以下のスクリプトをアーカイブチャネルソースファイル（4.6項 「アーカイブチャネルソースリストファイルのサンプル」を参照）と一緒に使用して、SUSE更新プログラムチャネルの四半期ごとのアーカイブを作成します。このサンプルスクリプトはBashで書かれていますが、クローン作成を実行するためにspacecmdを呼び出し、新しいアーカイブをパブリック（他の組織からもアクセス可能）に設定します。 ### ###
スクリプトの実行にはしばらく時間がかかります。クローンコマンドはすぐに終了しますが、実際にクローンされたチャネルが利用できるようになり、org-accessコマンドがチャネルにアクセスして処理を完了するまでにはしばらく時間がかかります。### ###これを手動でテストする場合は手間と時間がかかります。スクリプトの通常のcrontab実行はしばらくすると終了します。
#!/bin/bash
####################################################################
# SUMA Archive Channel Creation Script - Called from Cron #
# #
# This script creates quarterly archives of SUSE Manager #
# channels from SUSE Updates channels. It takes a list #
# of source channels from the archive-sources.lst file #
# that should be located in the same directory as this #
# script. Each entry in that file will be used as a #
# source channel to create an archive for patches/updates #
# in the appropriate archive channel. #
# #
# REQUIRES: #
# 1. cron entries for each quarter : #
# e.g. 30th of months June and Sept. and 31st of months March #
# and December: #
# 0 0 30 6,9 * /path/to/this/script #
# 0 0 31 3,12 * /path/to/this/script #
# #
# 2. archive-sources.lst : #
# A list of the architecture, the source updates channel #
# for each distro and the suffix of the target channel #
# version and architecture (1 per line - no line-feed at EOF) #
# Example: #
# S390x,sles11-sp3-updates-s390x,SLES11-SP3-Updates for s390x #
# ppc64,sles11-sp4-updates-ppc64,SLES11-SP4-Updates for PPC #
# x86_64,sles11-sp3-updates-x86_64,SLES11-SP3-Updates for x86_64 #
# etc. #
# #
####################################################################
# #
# Created by - Jeff Price, SUSE Consulting - 2015 #
# Updated for SUMA 3.1 & 3.2 - Levin Forrest, #
# Lenovo Consulting - 2018 #
# #
####################################################################
## date strings
month=`date +%m`
year=`date +%Y`
fdate=`date +%m-%d-%Y`
## set quarter
if [ $month -le 3 ]
then
quar=1
elif [ $month -gt 3 ] && [ $month -lt 7 ]
then
quar=2
elif [ $month -gt 6 ] && [ $month -lt 10 ]
then
quar=3
elif [ $month -gt 9 ]
then
quar=4
fi
## Create archives using source list
while read line
do
arch=`echo "$line" | awk -F, '{print $1}'`
src_ch=`echo "$line" | awk -F, '{print $2}'`
trg_ch=`echo "$line" | awk -F, '{print $3}'`
## set archive channel
## Note the target_parent requires this EXACT channel already created
target_parent=$arch"-patch-archives-channel"
source_channel=$src_ch
target_channel_name="Q"$quar" "$year" - "$fdate" - Archive of "$trg_ch
target_summary="Q"$quar"-"$year" Archive Set "$trg_ch
target_channel_label="q"$quar"-"$year"-archive-"$src_ch
## Debug Output
echo "Architecture: " $arch
echo "Source Channel: "$src_ch
echo "Target Channel Archive Suffix: "$trg_ch
echo "Target Archive Parent Channel: "$target_parent
echo "Source Channel (again): "$source_channel
echo "Target Channel Name: "$target_channel_name
lctn=`echo $target_channel_name|tr '[:upper:]' '[:lower:]'`
echo "lowercase target name: "$lctn
echo "Target Channel Label: "$target_channel_label
echo "Target Channel Summary and Description: "$target_summary
## removed double quotes from $src_ch to allow spacecmd to parse correctly
## removed single quotes from $target_channel_label and $target_parent to allow spacecmd to parse correctly
## only $target_channel_name should have single quotes as this variable contains spaces
/usr/bin/spacecmd -d -- softwarechannel_clone -s $src_ch -n "'$target_channel_name'" -l "$target_channel_label" -p "$target_parent" -g
## removed double quotes from $target_channel_label to allow spacecmd to parse correctly
/usr/bin/spacecmd -d -- softwarechannel_setorgaccess $target_channel_label -e
## added full directory structure to archive-sources location to allow call from crontab
done < /usr/sbin/archive-sources.lst4.6 アーカイブチャネルソースリストファイルのサンプル #
このファイルは、前のセクション（4.4項 「SUSE Manager 2.1および3.0用のアーカイブチャネル作成サンプルスクリプト」を参照）のアーカイブチャネル作成スクリプトによって呼び出されて使用されます。関数「readline」が使用されているため、ファイルにはデータを含む行しかないはずです。空白行はデータとして取得され、上記のアーカイブチャネル作成スクリプトではエラーが発生します。
最初のフィールドがアーキテクチャで、ソースの親アーカイブチャネルを定義します。ここに新しいアーカイブが子チャネルとして配置されます。2番目のフィールドがソースチャネルラベルで、ここからパッチ/パッケージを取得します。最後のフィールドはターゲットチャネルの名前指定に使用します。このフィールドはチャネル名の一部、およびチャネルの概要/説明フィールドの一部になります。
s390x,sles11-sp3-updates-s390x,SLES11-SP3-Updates for s390x x86_64,sles11-sp4-updates-x86_64,SLES11-SP4-Updates for x86_64 i586,sles11-sp3-updates-x86_64,SLES11-SP3-Updates for x86_64
4.7 spacecmdの自動認証 #
このサンプルアーカイブスクリプトはBashで書かれており、spacecmdシェルを呼び出します。spacecmdとSUSE Manager XMLRPC APIの通常実行には認証資格情報が必要です。アーカイブスクリプトをcronから正常に実行するには、要求されたときに適切なユーザー資格情報を渡すための何らかの方法が必要になります。しかし、心配はご無用です。ユーザーのユーザー名とパスワードを保存するための方法が用意されています。
初めてspacecmdユーティリティ/シェルを呼び出す際、spacecmdを呼び出したユーザーのホームディレクトリにディレクトリが1つ作成されます。このディレクトリの名前は.spacecmdとなります（「/root/.spacecmd/」など）。このディレクトリにはconfigというファイルがあります。「###」さらに、このファイルには今後ユーザーがspacecmdを呼び出す時に使用するパラメーターを保存できます。パラメーターは以下のとおりです（ユーザー名とパスワードは実際にお使いのものに置き換えてください）：
[spacecmd] server=localhost username=admin password=susemgr nossl=0
これらの資格情報が保存されたら、ユーザー名とパスワードを求められることなくspacecmdシェルやspacecmdコマンドをコマンドラインから呼び出すことができるようになります。
5 法的通知 #
Copyright ©2006–2020 SUSE LLC and contributors.All rights reserved.
本書は、GNU Free Documentation Licenseのバージョン1.2または（オプションとして）バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載してください。ライセンスバージョン1.2のコピーは、GNU Free Documentation Licenseセクションに含まれています。 「###」###
SUSE、SUSEのロゴ、およびYaSTは、米国およびその他の国におけるSUSE LLCの登録商標です。SUSEの商標については、http://www.suse.com/company/legal/を参照してください。Linuxは、Linus Torvaldsの登録商標です。本書に記載されているその他の名称や商標はすべて、それぞれの所有者の商標または登録商標の可能性があります。
この記事は、「SUSE Best Practices」と呼ばれる一連の文書の一部です。個々の文書は、SUSE社員および第三者が自主的に作成したものです。
この記事のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。
SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。参考までに、これらの記事の基になったライセンスを以下に示します。
6 GNU Free Documentation License #
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.
0. PREAMBLE #
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.
1. APPLICABILITY AND DEFINITIONS #
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.
2. VERBATIM COPYING #
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.
3. COPYING IN QUANTITY #
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.
4. MODIFICATIONS #
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:
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
State on the Title page the name of the publisher of the Modified Version, as the publisher.
Preserve all the copyright notices of the Document.
Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
Include an unaltered copy of this License.
Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.
Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.
Preserve any Warranty Disclaimers.
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.
5. COMBINING DOCUMENTS #
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".
6. COLLECTIONS OF DOCUMENTS #
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.
7. AGGREGATION WITH INDEPENDENT WORKS #
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.
8. TRANSLATION #
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.
9. TERMINATION #
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.
10. FUTURE REVISIONS OF THIS LICENSE #
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.
ADDENDUM: How to use this License for your documents #
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.