このガイドでは、SUSE Linux Enterprise Serverのアップグレードについて説明します。SUSE Linux Enterprise Serverを他のSLE製品や拡張機能の基本システムとして使用している場合は、それらの製品ドキュメントも参照して、本製品または拡張機能に固有のアップグレード情報も確認してください。
- 序文
- 1 アップグレードパスと方法
- 2 ライフサイクルとサポート
- 3 アップグレードの準備
- 3.1 現在のシステムが最新であることを確認する
- 3.2 リリースノートの確認
- 3.3 バックアップの作成
- 3.4 インストール済みパッケージとリポジトリの一覧
- 3.5 SUSE Linux Enterprise Server 11 SP4からのアップグレード
- 3.6 PostgreSQLデータベースのマイグレート
- 3.7 仮想マシンゲストのシャットダウン
- 3.8 SMTクライアントセットアップの調整
- 3.9 ディスクスペース
- 3.10 SLE 12から15へAutoYaSTプロファイルの変更
- 3.11 登録管理ツール(SMT)サーバのアップグレード
- 3.12 カーネルのマルチバージョンサポートの一時的な無効化
- 3.13 IBM Zでのアップグレード
- 3.14 IBM POWER: Xサーバの起動
- 4 オフラインでのアップグレード
- 5 オンラインでのアップグレード
- 6 ソースコードのバックポート
- A GNU licenses
Copyright © 2006–2024 SUSE LLC and contributors.All rights reserved.
この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、配布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。
SUSEの商標については、https://www.suse.com/company/legal/を参照してください。その他の第三者のすべての商標は、各社の所有に帰属します。商標記号(®、 ™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。
序文 #
1 利用可能なマニュアル #
- オンラインマニュアル
本製品のオンラインマニュアルは、https://documentation.suse.com/#slesで入手できます。様々な形式のマニュアルをブラウズまたはダウンロードできます。
他の製品のオンラインマニュアルは、https://documentation.suse.com/で検索してください。
注記: 最新のアップデート最新のマニュアルアップデートは、通常、英語版マニュアルで入手できます。
- リリースノート
リリースノートはhttps://www.suse.com/releasenotes/を参照してください。
- ご使用のシステムで
オフラインで利用するには、システムの
/usr/share/doc
にインストールされたマニュアルを確認してください。「マニュアルページ」には、多くのコマンドについても詳しく説明されています。説明を表示するには、man
コマンドに確認したいコマンドの名前を付加して実行してください。システムにman
コマンドがインストールされていない場合は、sudo zypper install man
コマンドでインストールします。
2 ドキュメントの改善 #
このドキュメントに対するフィードバックや貢献を歓迎します! 次のチャネルがあります。
- サービス要求およびサポート
ご使用の製品に利用できるサービスとサポートのオプションについては、https://www.suse.com/support/を参照してください。
サービス要求を開くには、SUSE Customer Centerでの購読が必要です。https://scc.suse.com/support/requestsからログインして をクリックしてください。
- バグレポート
https://bugzilla.suse.com/から入手できるドキュメントを使用して、問題を報告してください。このプロセスを簡略化するために、このドキュメントのHTMLバージョンの見出しの横にある リンクを使用できます。リンクを使用すると、Bugzillaで適切な製品とカテゴリが事前に選択され、現在のセクションへのリンクが追加されます。バグレポートの入力を直ちに開始できます。Bugzillaアカウントが必要です。
- ドキュメントの編集に貢献
このドキュメントに貢献するには、このドキュメントのHTMLバージョンの見出しの横にある
リンクを使用してください。GitHubのソースコードに移動し、そこからプル要求を提出できます。GitHubアカウントが必要です。このドキュメントに使用されるドキュメント環境に関する詳細については、リポジトリのREADMEを参照してください。
- メール
ドキュメントに関するエラーの報告やフィードバックは<doc-team@suse.com>宛に送信してください。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してください。関連するセクション番号とタイトル(またはURLを含めて)、問題の簡潔な説明を記載してください。
3 マニュアルの表記規則 #
このマニュアルでは、次の通知と表記規則が使用されています。
/etc/passwd
:ディレクトリ名とファイル名PLACEHOLDER:PLACEHOLDERは、実際の値で置き換えられます
PATH
:環境変数PATHls
、--help
:コマンド、オプション、およびパラメータuser
:ユーザまたはグループpackage name: パッケージの名前
Alt、Alt–F1 :使用するキーまたはキーの組み合わせ、キーはキーボード上と同様、大文字で表示される
AMD/Intel この説明は、AMD64/Intel 64アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。
IBM Z, POWER この説明は、
IBM Z
およびPOWER
の各アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章への参照です。
root
特権で実行する必要のあるコマンド。多くの場合、これらのコマンドの先頭にsudo
コマンドを置いて、特権のないユーザとしてコマンドを実行することもできます。root #
command
tux >
sudo
command
特権のないユーザでも実行できるコマンド。
tux >
command
通知
警告: 警告の通知続行する前に知っておくべき、無視できない情報。セキュリティ上の問題、データ損失の可能性、ハードウェアの損傷、または物理的な危険について警告します。
重要: 重要な通知続行する前に知っておくべき重要な情報です。
注記: メモの通知追加情報。たとえば、ソフトウェアバージョンの違いに関する情報です。
ヒント: ヒントの通知ガイドラインや実際的なアドバイスなどの役に立つ情報です。
4 サポート #
SUSE Linux Enterprise Serverのサポートステートメントと、技術プレビューに関する概要を以下に示します。製品ライフサイクルの詳細については、第2章 「ライフサイクルとサポート」を参照してください。
サポート資格をお持ちの場合、Book “管理ガイド”, Chapter 39 “サポート用システム情報の収集”を参照して、サポートチケットの情報を収集する方法の詳細を確認してください。
4.1 SUSE Linux Enterprise Serverのサポートステートメント #
サポートを受けるには、SUSEの適切な購読が必要です。利用可能なサポートサービスを具体的に確認するには、https://www.suse.com/support/にアクセスして製品を選択してください。
サポートレベルは次のように定義されます。
- L1
問題の判別。互換性情報、使用サポート、継続的な保守、情報収集、および利用可能なドキュメントを使用した基本的なトラブルシューティングを提供するように設計されたテクニカルサポートを意味します。
- L2
問題の切り分け。データの分析、お客様の問題の再現、問題領域の特定、レベル1で解決できない問題の解決、またはレベル3の準備を行うように設計されたテクニカルサポートを意味します。
- L3
問題解決。レベル2サポートで特定された製品の欠陥を解決するようにエンジニアリングに依頼して問題を解決するように設計されたテクニカルサポートを意味します。
契約されているお客様およびパートナーの場合、SUSE Linux Enterprise Serverでは、次のものを除くすべてのパッケージに対してL3サポートを提供します。
技術プレビュー。
サウンド、グラフィック、フォント、およびアートワーク。
追加の顧客契約が必要なパッケージ。
モジュール「Workstation Extension」の一部として出荷される一部のパッケージは、L2サポートのみです。
パッケージ名が-develで終わるパッケージ(ヘッダファイルなどの開発用リソースが含まれるパッケージ)のサポートを受けるには、そのメインパッケージが必要です。
SUSEは、元のパッケージの使用のみをサポートします。つまり、変更も、再コンパイルもされないパッケージをサポートします。
4.2 技術プレビュー #
技術プレビューとは、今後のイノベーションを垣間見ていただくための、SUSEによって提供されるパッケージ、スタック、または機能を意味します。プレビューは、使用中の環境内で新しいテクノロジーをテストする際の利便性のために用意されています。私たちはフィードバックを歓迎しています。技術プレビューをテストする場合は、SUSEの担当者に連絡して、経験や使用例をお知らせください。お客様からの情報を、今後の開発に役立てさせていただきます。
ただし、技術プレビューには、次の制限事項があります。
技術プレビューはまだ開発中です。したがって、機能が不完全であったり、不安定であったり、何らかの理由で運用環境での使用には適していなかったりする場合があります。
技術プレビューにはサポートが提供されません。
技術プレビューは、特定のハードウェアアーキテクチャでしか利用できないことがあります。
技術プレビューの詳細および機能は、変更される場合があります。そのため、今後リリースされる技術プレビューへのアップグレードができない場合や、再インストールが必要となる場合があります。
技術プレビューは、任意の時点で終了する可能性があります。たとえば、SUSEでプレビューがお客様または市場のニーズを満たしていない、またはエンタープライズ基準に準拠していないことが判明した場合などです。SUSEでは、このようなテクノロジーのサポートされるバージョンを将来的に提供できない場合があります。
ご使用の製品に付属している技術プレビューの概要については、https://www.suse.com/releasenotes/にあるリリースノートを参照してください。
1 アップグレードパスと方法 #
SUSE® Linux Enterprise (SLE)では、既存のシステムを新しいバージョンにアップグレードできます。たとえば、SLE 12 SP4を最新のSLE 15サービスパックにアップグレードできます。新たにインストールする必要はありません。ホームディレクトリ、データディレクトリ、システム設定などの既存のデータは、そのまま保持されます。CD/DVDドライブから、またはネットワーク上にある中央のインストールソースからアップデートできます。
この章では、DVD、ネットワーク、自動化プロセス、SUSE Managerなどを使用して、SUSE Linux Enterprise システムを手動でアップグレードする方法について説明します。
1.1 アップグレードと新規インストールの比較 #
SUSEはSUSE Linux Enterprise Serverの2つのメジャーリリース間のアップデートをサポートしています。アップグレードと新規インストールのどちらが適切かは、特定のシナリオによって異なります。アップグレードの方が作業は少なくなりますが、新規インストールを行うと、リリースされた新機能のメリットを最大限受けられます。たとえば、ディスクレイアウトの変更、特定のファイルシステム機能、およびその他の改善などです。利用中のシステムを最大限活用するため、SUSEでは多くの場合、新規インストールをお勧めします。
アップグレードと新規インストールのどちらを採用する場合も、システム設定とデフォルト値が要件に合っていることを確認する必要があります。
特定のリリースのサービスパックから同じコードストリームの別のサービスパックにアップデートする場合は、新規インストールではなくアップグレードをお勧めします。とはいえ、このケースでも新規インストールを行う理由やシナリオも考えられます。どちらが適切かを判断できるのはお客様だけです。
1.2 SLES 15 SP3へのサポートされているアップグレードパス #
マイグレーションを実行する前に、第3章 「アップグレードの準備」をご覧ください。
クロスアーキテクチャアップグレードは「サポートされません」。たとえば、32ビットバージョンのSUSE Linux Enterprise Serverから64ビットバージョンへのアップグレードや、ビッグエンディアンからリトルエンディアンへのアップグレードなどがこれに該当します。
具体的には、POWER版のSLE 11(ビッグエンディアン)からPOWER版のSLE 15 SP3(新規: リトルエンディアン)はサポートされません。
同様に、SUSE Linux Enterprise 15は、64ビット専用であるため、32ビットのSUSE Linux Enterprise 11システムからSUSE Linux Enterprise 15以降へのアップグレードもサポートされません。
クロスアーキテクチャアップグレードを行いたい場合は、新規インストールを実行する必要があります。
最も単純なアップグレードパスは、すべてのサービスパックを連続してインストールすることです。SUSE Linux Enterprise 15製品ライン(GAとそれ以降のサービスパック)については、アップグレード時に1つのサービスパックをスキップすることもサポートされています。たとえば、SLE 15 GAからSLE 15 SP2へのアップグレードや、SLE 15 SP1からSLE 15 SP3へのアップグレードがサポートされます。
この章で説明しているアップグレードパスは、マシンのOSとしてのSUSE Linux Enterpriseだけに適用されます。SUSE Linux Enterpriseが実行するすべてのアプリケーションに適用されるわけではありません。PostgreSQLやMariaDBデータベースなどのワークロードを使用している場合、データベースをアップグレードする前に、介在するOSのアップグレードが必要になる場合があります。
OSのアップグレードを行う前に、リリースノートでデータベースのバージョンを確認してください。新しいメジャーバージョンが出荷される場合、アップグレード手順について第3章 「アップグレードの準備」を参照してください。
- SUSE Linux Enterprise Server 11 GA / SP1 / SP2 / SP3 / SP4からのアップグレード
SLES 11 SP4以前のサービスパックから直接アップグレードすることは、サポートされていません。SLES 15 SP3に進むには、まずSLES 11 SP4 LTSSが必要です。
新規インストールを行うことができない場合は、まず、SLES 11サービスパックをSLES 11 SP4 LTSSにアップグレードします。このアップグレードについては、SLES 11 SP4 『導入ガイド』を参照してください。
- SUSE Linux Enterprise Server 11 SP4 LTSSからのアップグレード
SLES 11 SP4からのアップグレードはオフラインアップグレードを介してのみサポートされます。詳細については、第4章 「オフラインでのアップグレード」を参照してください。
- SUSE Linux Enterprise Server 12 GA / SP1 / SP2 / SP3 / SP4からのアップグレード
SLES 12 SP4以前のサービスパックから直接アップグレードすることは、サポートされていません。SLES 15 SP3に進むには、まずSLES 12 SP5が必要です。
新規インストールを行うことができない場合は、まず、SLES 12サービスパックをSLES 12 SP5にアップグレードします。このアップグレードについては、SLES 12 SP5 『導入ガイド』を参照してください。
- SUSE Linux Enterprise Server 12 SP3 LTSS / SP4 LTSSからのアップグレード
SLES 12 SP3 LTSSまたはSP4 LTSSからのアップグレードは、オフラインアップグレードでのみサポートされます。詳細については、第4章 「オフラインでのアップグレード」を参照してください。
- SUSE Linux Enterprise Server 12 SP5からのアップグレード
SLES 12 SP5からのアップグレードはオフラインアップグレードを介してのみサポートされます。詳細については、第4章 「オフラインでのアップグレード」を参照してください。
- SUSE Linux Enterprise Server 15 GAからのアップグレード
SLES 15 GAから直接アップグレードすることは、サポートされていません。SLES 15 SP3に進むには、まずSLES 15 SP1が必要です。
- SUSE Linux Enterprise Server 15 SP1 / SP2からのアップグレード
SLES 15 SP1またはSP2からのアップグレードは、オンラインとオフラインのどちらもサポートされています。詳細については、1.3項 「オンラインアップグレードとオフラインアップグレード」を参照してください。
- SUSE Linux Enterpriseのパブリッククラウドゲストのアップグレード
パブリッククラウドでのSLEゲストのアップグレードについては、Using the SUSE Distribution Migration Systemを参照してください。
- openSUSE Leap 15からのアップグレード
openSUSE Leap 15からのアップグレードはサポートされています。5.9項 「openSUSE LeapからSUSE Linux Enterprise Serverへのアップグレード」を参照してください。Leapのサーバインストールのみがアップグレードをサポートされています。
1.3 オンラインアップグレードとオフラインアップグレード #
SUSEは、次のアップグレードおよびマイグレーションの方法をサポートしています。用語の詳細については、2.1項 「用語集」を参照してください。次の2つの方法があります。
- オンライン
実行中のオペレーティングシステム自体から実行されるアップグレード(システムが稼働中の状態)。例: ZypperまたはYaSTを使用したオンラインアップデート、SUSEカスタマーセンターまたはリポジトリミラーリングツール(RMT)を介して接続、SUSE Managerを介したソルトポリシー。
詳細については、第5章 「オンラインでのアップグレード」を参照してください。
同じメジャーリリースのサービスパック間でマイグレートする場合は、5.4項 「オンラインマイグレーションツール(YaST)を使用したアップグレード」または5.5項 「Zypperによるアップグレード」に従うことをお勧めします。
- オフライン
オフラインアップグレードは、アップグレードされるオペレーティングシステムが稼働して「いない」こと(システムダウン状態)を意味します。代わりに、ターゲットオペレーティングシステムのインストーラが起動し(インストールメディアから、ネットワークまたはローカルブートローダを介して)、アップグレードを実行します。
詳細については、第4章 「オフラインでのアップグレード」を参照してください。
マシンがSUSE Managerによって管理されている場合は、SUSE Managerドキュメントの説明に従ってアップデートしてください。「Client Migration」の手順については、https://documentation.suse.com/suma/で入手可能な『SUSE Manager Upgrade Guide』を参照してください。
2 ライフサイクルとサポート #
この章では、専門用語、SUSE製品ライフサイクル、サービスパックリリース、および推奨されるアップグレードポリシーに関するバックグラウンド情報について説明します。
2.1 用語集 #
このセクションでは、いくつかの用語を使用します。それらの情報を理解するには、次の定義をお読みください。
- バックポート
バックポートとは、新しいバージョンのソフトウェアによる特定の変更内容を採用し、それを古いバージョンに適用することを意味します。最も一般的な使用事例は、古いソフトウェアコンポーネントのセキュリティホールの修正です。通常は、拡張機能や(頻度は低いものの)新機能を提供するための保守モデルの一部にもなります。
- デルタRPM
デルタRPMは、パッケージに定義された2つのバージョンどうしのバイナリ差分のみで構成されているので、ダウンロードサイズが最小限ですみます。インストールの前に、RPMのフルパッケージがローカルコンピュータ上で再構築されます。
- ダウンストリーム
オープンソースワールドにおけるソフトウェア開発方法のメタファーです(アップストリームと対比)。「ダウンストリーム」という用語は、アップストリームからのソースコードを他のソフトウェアと統合し、エンドユーザが使用するためのディストリビューションを構築する、SUSEのような人や組織を指しています。つまり、ソフトウェアは開発者からインテグレータを介して、エンドユーザーまで、ダウンストリーム(下向き)に流れていきます。
- 拡張機能, アドオン製品
拡張機能およびサードパーティのアドオン製品は、SUSE Linux Enterprise Server製品に付加価値機能を提供します。これらはSUSEおよびSUSEパートナーによって提供され、基本製品であるSUSE Linux Enterprise Serverにインストールして登録します。
- LTSS
LTSSはLong Term Service Pack Supportの略で、SUSE Linux Enterprise Serverの拡張機能として提供されています。
- メジャーリリース, 一般出荷(GA)バージョン
SUSE Linux Enterprise (または任意のソフトウェア製品)のメジャーリリースとは、新しい機能やツールを導入する、非推奨になっていたコンポーネントを削除する、後方互換性のない変更が存在する、などの特徴を持った新バージョンです。たとえば、SUSE Linux Enterprise 12または15はメジャーリリースです。
- マイグレーション
それぞれのパッチをインストールするために、オンラインアップデートツールまたはインストールメディアを使用して、サービスパック(SP)への更新を行うことです。インストール済みシステムのすべてのパッケージを最新状態にアップデートします。
- マイグレーションターゲット
システムを移行できる互換性のある製品のセットです。製品や拡張機能のバージョン、リポジトリのURLが含まれています。マイグレーションターゲットは、時間の経過とともに変化し、インストール済みの拡張機能によって異なります。SLE 15 SP1やSES 6など、複数のマイグレーションターゲットを選択できます。
- モジュール
モジュールは、SUSE Linux Enterprise Serverで全面的にサポートされている構成要素であり、アドオン製品とは異なるライフサイクルを備えています。モジュールは、明確に定義された適用範囲を持ち、オンラインチャネルでのみ配布されています。これらのチャネルに登録するには、SUSEカスタマーセンター、RMT(リポジトリミラーリングツール)、またはSUSE Managerへの登録が前提条件になります。
- パッケージ
パッケージは、
rpm
形式で圧縮されたファイルで、特定のプログラムのすべてのファイルが格納されています。環境設定、サンプル、ドキュメントなどのオプションコンポーネントも含まれます。- パッチ
パッチは、1つ以上のパッケージから成り、デルタRPMで適用できます。また、まだインストールされていないパッケージへの依存関係を導入することもあります。
- サービスパック(SP)
複数のパッチを組み合わせて、インストールまたは展開しやすい形式にします。サービスパックには番号が付けられ、通常、プログラムのセキュリティ修正、更新、アップグレード、または拡張機能が含まれます。
- アップストリーム
オープンソースワールドにおけるソフトウェア開発方法のメタファーです(ダウンストリームと対比)。アップストリームという用語は、ソースコードとして配布されるソフトウェアの元のプロジェクト、作者、またはメンテナンス者を指しています。フィードバック、パッチ、拡張機能、その他の改良機能は、エンドユーザまたはコントリビュータからアップストリーム(上流)の開発者に流れていきます。開発者は、リクエストを組み込むのか却下するのか決定します。
プロジェクトメンバーがリクエストを組み込むように決定すると、それが新しいバージョンのソフトウェアに出現します。受け入れられたリクエストは、すべての関係者にメリットをもたらします。
リクエストが受け入れられない場合は、別の理由が考えられます。プロジェクトのガイドラインに準拠していない、無効である、すでに組み込まれている、プロジェクトに関係ないかロードマップ上に存在しないなどの状態のいずれかが理由です。リクエストが受け入れられない場合、アップストリームの開発者にとっては、自分のパッチをアップストリームのコードと同期させる必要があるために困難が生じます。この操作は一般的には回避されますが、まだ必要な場合もあります。
- この状態から
新しいマイナーバージョンのパッケージのインストールです。通常、セキュリティやバグの修正が含まれています。
- アップグレード
パッケージまたは配布の新しい主要バージョンのインストール。これにより新機能がもたらされます。アップグレードオプションの違いについては、1.3項 「オンラインアップグレードとオフラインアップグレード」を参照してください。
2.2 製品のライフサイクル #
SUSEの製品のライフサイクルは以下のとおりです。
SUSE Linux Enterprise Serverのライフサイクルは13年です。そのうち10年間は一般サポート、3年間は拡張サポートが適用されます。
SUSE Linux Enterprise Desktopのライフサイクルは10年です。そのうち7年間は一般サポート、3年間は拡張サポートが適用されます。
メジャーリリースは4年ごとに提供されます。サービスパックは12カ月から14カ月ごとに提供されます。
古いサービスパックは、新しいサービスパックのリリース後6カ月間サポートされます。図2.1「メジャーリリースとサービスパック」に、具体的に示します。
アップグレード計画を設計、検証、およびテストするためにさらに時間が必要な場合、長期サービスパックサポートを利用してサポートを延長することにより、12~36カ月間、追加サポートを受けることができます。これは12カ月単位で延長でき、どのサービスパックに対しても合計2~5年のサポートを利用できます。詳細については、図2.2「長期サービスパックサポート」を参照してください。
詳細については、https://www.suse.com/products/long-term-service-pack-support/を参照してください。
ライフサイクル、リリース頻度、およびオーバーレイサポート期間の詳細については、https://www.suse.com/lifecycleを参照してください。
2.3 モジュールの依存関係とライフサイクル #
モジュールの一覧、それらの依存関係、およびライフサイクルについては、Article “Modules and Extensions Quick Start”を参照してください。
2.4 定期的なライフサイクルレポートの生成 #
SUSE Linux Enterprise Serverは、インストールされている全製品のサポートステータスに変更がないかどうかを定期的に確認し、変更がある場合は電子メールでレポートを送信できます。レポートを生成するには、 zypper-lifecycle-plugin
を、zypper in zypper-lifecycle-plugin
を使用してインストールします。
systemctl
を使用して、システムでレポートの生成を有効にします。
root #
systemctl
enable lifecycle-report
テキストエディタを使用して、ファイル/etc/sysconfig/lifecycle-report
で、レポート電子メールの受信者と件名のほかにレポート生成周期を設定できます。設定MAIL_TO
およびMAIL_SUBJ
はメールの受信者と件名を定義し、DAYS
はレポート生成周期を設定します。
レポートにはサポートステータスの変更が表示されます。これは変更発生後に表示され、事前には表示されません。最後のレポートの生成直後に変更が発生した場合、変更が通知されるまでに最大14日かかる可能性があります。DAYS
オプションを設定する際は、この点を考慮に入れてください。次の設定エントリを要件に合わせて変更します。
MAIL_TO='root@localhost' MAIL_SUBJ='Lifecycle report' DAYS=14
最新レポートはファイル/var/lib/lifecycle/report
にあります。このファイルは2つのセクションで構成されます。最初のセクションには、使用製品のサポート終了に関する情報が表示されます。2番目のセクションには、パッケージ、およびそのサポート終了日とアップデートの有無が一覧にされます。
2.5 サポートレベル #
拡張サポートレベルの範囲は、10年目から13年目までになります。これらのサポートレベルには、継続されるL3エンジニアリングレベルの診断とリアクティブな重大なバク修正が含まれます。これらのサポートレベルでは、カーネルで容易に悪用可能なルートエクスプロイトや、ユーザの介入なしに直接実行可能な他のルートエクスプロイトに対するアップデートを利用できます。さらに、限られたパッケージ除外リストを使用して、既存のワークロード、ソフトウェアスタック、およびハードウェアをサポートします。概要については、表2.1「セキュリティ更新とバグの修正」を参照してください。
最新のサービスパック(SP)の一般サポート |
古いSPの一般サポート(LTSS利用時) |
LTSS利用時の拡張サポート | |||
---|---|---|---|---|---|
機能 |
1~5年目 |
6~7年目 |
8~10年目 |
4~10年目 |
10~13年目 |
テクニカルサービス |
はい |
はい |
はい |
はい |
はい |
パッチおよび修正の利用 |
はい |
はい |
はい |
はい |
はい |
マニュアルおよびナレッジベースの利用 |
はい |
はい |
はい |
はい |
はい |
既存のスタックおよびワークロードのサポート |
はい |
はい |
はい |
はい |
はい |
新規展開のサポート |
はい |
はい |
制限あり(パートナーおよび顧客の要求に基づく) |
制限あり(パートナーおよび顧客の要求に基づく) |
いいえ |
拡張リクエスト |
はい |
制限あり(パートナーおよび顧客の要求に基づく) |
制限あり(パートナーおよび顧客の要求に基づく) |
いいえ |
いいえ |
ハードウェアの有効化および最適化 |
はい |
制限あり(パートナーおよび顧客の要求に基づく) |
制限あり(パートナーおよび顧客の要求に基づく) |
いいえ |
いいえ |
SUSE SolidDriverプログラム(旧名称はPLDP)によるドライバのアップデート |
はい |
はい |
制限あり(パートナーおよび顧客の要求に基づく) |
制限あり(パートナーおよび顧客の要求に基づく) |
いいえ |
最新のSPからの修正のバックポート |
はい |
はい |
制限あり(パートナーおよび顧客の要求に基づく) |
該当なし |
該当なし |
セキュリティの更新1 |
すべて(All) |
すべて(All) |
すべて(All) |
クリティカルのみ |
クリティカルのみ |
欠陥の解決 |
はい |
はい |
制限あり(セキュリティレベル1および2の欠陥のみ) |
制限あり(セキュリティレベル1および2の欠陥のみ) |
制限あり(セキュリティレベル1および2の欠陥のみ) |
1 SUSE Linux Enterprise Update Policyの詳細については、次のナレッジベース記事を参照してください。
2.6 マシンのSUSEConnectへの登録および登録解除 #
登録時には、システムはSUSEカスタマーセンター(https://scc.suse.com/を参照)、またはSMTなどのローカル登録プロキシからリポジトリを受け取ります。リポジトリ名はカスタマセンター内の特定のURIにマップされています。ご使用のシステムで使用可能なすべてのリポジトリを一覧にするには、次のようにzypper
を使用します。
root #
zypper
repos -u
これにより、ご使用のシステムで使用可能なすべてのリポジトリのリストが表示されます。リポジトリごとに、別名、名前、有効かどうか、リフレッシュされるかどうかといった情報がリストされます。オプション-u
を使用すると、元となるURIも表示されます。
たとえば、ご使用のマシンを登録するには、SUSEConnectを実行します。
root #
SUSEConnect
-r REGCODE
ご使用のマシンの登録を解除する場合も、SUSEConnectを使用できます。
root #
SUSEConnect
--de-register
ローカルにインストールされている製品とそのステータスを確認するには、次のコマンドを使用します。
root #
SUSEConnect
-s
2.7 SLEバージョンの特定 #
SLEインストールのバージョンを特定する必要がある場合は、ファイル/etc/os-release
のコンテンツを確認します。
マシンで読み込み可能なXML出力はzypper
で生成できます。
tux >
zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?> <stream> <product-list> <product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product> </product-list> </stream>
3 アップグレードの準備 #
アップグレード手順を開始する前に、システムが正しく準備されていることを確認します。準備内容には、データのバックアップとリリースノートの確認などがあります。以下の章では、順を追って手順を説明します。
3.1 現在のシステムが最新であることを確認する #
システムのアップグレードは、最新のパッチレベルからのみサポートされます。zypper patch
を実行するか、YaSTモジュール を実行して、最新のシステムの更新がインストールされていることを確認します。
3.2 リリースノートの確認 #
リリースノートですべての変更点、新機能、および既知の問題のリストを確認してください。docu
ディレクトリのインストールメディアからもリリースノートを確認できます。
通常、リリースノートにはそれに続く2つのリリースの変更しか記載されていません。サービスパックを1つ以上スキップする場合は、スキップするサービスパックのリリースノートも確認します。
リリースノートを参照して以下を確認します。
使用しているハードウェアに特別な配慮が必要かどうか
使用しているソフトウェアパッケージに大幅な変更があるかどうか
インストールのために特別な予防措置が必要かどうか
3.3 バックアップの作成 #
アップグレードの前に、既存の設定ファイルを別のメディア(テープデバイスやリムーバブルハードディスクなど)にコピーして、データをバックアップしてください。主に、/etc
に保存されているファイル、および/var
と/opt
のディレクトリとファイルの一部に当てはまります。さらに、/home
(HOME
ディレクトリ)下のユーザデータをバックアップメディアに書き込むようにします。
すべてのデータは、root
ユーザでバックアップします。root
のみに、すべてのローカルファイルに関する十分なパーミッションがあります。
YaSTのインストールモードとして/etc/sysconfig
ディレクトリにあるファイルを含めることができます。ただし、これは完全なバックアップではありません。前述したその他の重要なディレクトリがすべて含まれていないからです。/var/adm/backup
ディレクトリでバックアップを見つけます。
3.4 インストール済みパッケージとリポジトリの一覧 #
インストール済みパッケージのリストを記録できます。たとえば、新しいメジャーSLEリリースを新規インストールする場合や、旧バージョンに戻す場合などです。
インストール済みパッケージまたは使用中のリポジトリの中にはSUSE Linux Enterpriseの最新リリースで利用できないものもあることに注意してください。名前が変更されていたり、ほかのパッケージやリリースに置き換えられていたりすることもあります。また、レガシ目的で引き続き提供されていても、デフォルトでは別のパッケージが使用されるパッケージもあります。したがって、ファイルを多少手動で編集しなければならない場合があります。これはテキストエディタで実行できます。
使用中のすべてのリポジトリのリストを記述した
repositories.bak.repo
という名前のファイルを作成します。root #
zypper
lr -e repositories.bakさらに、すべてのインストール済みパッケージのリストを記述した
installed-software.bak
という名前のファイルも作成します。root #
rpm
-qa --queryformat '%{NAME}\n' > installed-software.bak両方のファイルをバックアップします。これらのリポジトリとインストール済みパッケージは、次のコマンドで復元できます。
root #
zypper
ar repositories.bak.reporoot #
zypper
install $(cat installed-software.bak)注記: 新しいメジャーリリースへの更新によりパッケージ数が増える新しいメジャーバージョン(SLE X+1)にアップグレードされるシステムには、最初のシステム(SLE X)より多くのパッケージが含まれる場合があります。同じパターンを選択したSLE X+1の新規インストールよりも多くのパッケージが含まれる場合もあります。その理由は次のとおりです。
パッケージをより細かく選択できるように、パッケージが分割されています。たとえば、SLE 11の37個の texlive パッケージは、SLE 15では3000個のパッケージに分割されました。
パッケージが分割された際、以前のバージョンと同じ機能を保つために、新しいパッケージはすべて、アップグレードとしてインストールされるようになりました。ただし、SLE X+1の新規インストールの新しいデフォルトでは、すべてのパッケージをインストールしない場合があります。
SLE Xからの古いパッケージが、互換性の理由で保持されている可能性があります。
パッケージの依存関係およびパターンの範囲が変更されている可能性があります。
3.5 SUSE Linux Enterprise Server 11 SP4からのアップグレード #
SUSE Linux Enterprise Server 11 SP4でMySQL、PostgreSQL、またはJava MD5ベースの証明書を使用している場合は、次のセクションの説明に従ってシステムを準備してください。また、この章の他のセクションも参照して、さらに必要な準備を確認してください。
3.5.1 PostgreSQLデータベースのマイグレート #
SUSE Linux Enterprise Server 11でPostgreSQLデータベースを使用している場合は、データベースのアップグレードが必要です。詳細については、3.6項 「PostgreSQLデータベースのマイグレート」を参照してください。
3.5.2 MySQLデータベースのマイグレート #
SUSE Linux Enterprise 12では、SUSEは、MySQLからMariaDBに切り替えました。アップグレードを開始する前に、データベースのバックアップを取得することを強くお勧めします。
データベースマイグレーションを実行するには、次の手順を実行します。
ご使用のSUSE Linux Enterprise 11マシンにログインします。
ダンプファイルを作成します。
root #
mysqldump
-u root -p --all-databases > mysql_backup.sqlデフォルトでは、
mysqldump
は、INFORMATION_SCHEMA
、またはperformance_schema
データベースをダンプしません。詳細については、https://dev.mysql.com/doc/refman/5.5/en/mysqldump.htmlを参照してください。ダンプファイル、環境設定ファイル、
/etc/my.cnf
、およびディレクトリ、/etc/mysql/
を後で調べることができるように(インストールのためではありません)安全な場所に保存します。SUSE Linux Enterprise Serverのアップグレードを実行します。アップグレードが終わっても、前の環境設定ファイル、
/etc/my.cnf
は前のままです。新しい設定は、/etc/my.cnf.rpmnew
ファイルで確認できます。必要に応じて、MariaDBデータベースを設定します。以前の環境設定ファイルとディレクトリを使わないでください。これらは、リマインダとして使用し、活用するだけです。
MariaDBサーバを起動して確認してください。
root #
systemctl
start mariadbブートのたびにMariaDBサーバを起動する場合は、そのサービスを有効にします。
root #
systemctl
enable mariadbMariaDBが適切に稼働していることを、データベースに接続して確認します。
root #
mariadb
-u root -p
3.5.3 JavaアプリケーションのMD5以外のサーバ証明書の作成 #
SP1からSP2に更新するときに、MD5ベースの証明書はセキュリティ修正の一環として無効にされました。MD5として作成された証明書を持っている場合、次の手順で証明書を再作成してください。
端末を開いて、
root
としてログインします。秘密鍵を作成します。
root #
openssl
genrsa -out server.key 1024より強力な鍵が必要な場合、
1024
を4096
などの大きい数に置き換えます。証明書署名要求(CSR)を作成します。
root #
openssl
req -new -key server.key -out server.csr証明書を自己署名します。
root #
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crtPEMファイルを作成します。
root #
cat
server.key server.crt > server.pemファイル
server.crt
、server.csr
、server.key
、およびserver.pem
を鍵が見つかったそれぞれのディレクトリに配置します。たとえばTomcatの場合、このディレクトリは/etc/tomcat/ssl/
です。
3.6 PostgreSQLデータベースのマイグレート #
SUSE Linux Enterprise Server 15 SP3は、PostgreSQLデータベースのバージョン10、12、13とともに出荷されます。デフォルトはバージョン13です。ただし、古いバージョンのSUSE Linux Enterprise Serverからアップグレードするためのレガシ
モジュールにはバージョン10と12が含まれます。
データベースのマイグレーション作業が必要であることから、自動アップグレードプロセスはありません。そのため、あるバージョンから別のバージョンへの切り替えは手動で行う必要があります。
マイグレーションプロセスは、pg_upgrade
コマンドで行います。このコマンドは、従来のdumpとreloadコマンドに代わる方式です。「dump & reload」方式と比べてpg_upgrade
の方がマイグレーション時間が短くなります。
各PostgreSQLバージョンのプログラムファイルは、異なる、バージョン依存のディレクトリに格納されます。たとえば、バージョン9.6の場合は/usr/lib/postgresql96/
、バージョン10の場合は/usr/lib/postgresql10/
、バージョン12の場合は/usr/lib/postgres12/
に格納されます。PostgreSQLのバージョニングポリシーが、メジャーバージョン9.6と10の間で変更されていることに注意してください。詳細については、https://www.postgresql.org/support/versioning/を参照してください。
SLE 11からアップグレードする場合、postgresql94
がアンインストールされ、PostgreSQLのより高いバージョンにデータベースをマイグレーションするために使用できません。したがって、この場合、システムをアップグレードする「前に」PostgreSQLデータベースをマイグレートしてください。
以下の手順は、バージョン9.6から10へのデータベースマイグレーションについて説明しています。スタートまたはターゲットとして異なるバージョンを使用する場合は、それに応じてバージョン番号を置き換えます。
データベースマイグレーションを実行するには、次の手順を実行します。
以下の前提条件が満たされていることを確認します。
満たされていない場合、保守アップデートで、古いPostgreSQLバージョンを最新リリースにアップグレードします。
既存のデータベースのバックアップを作成します。
新規のPostgreSQLのメジャーバージョンのパッケージをインストールします。SLES15 SP3の場合、これは postgresql10-server およびそれが依存するすべてのパッケージのインストールを意味します。
パッケージ postgresql10-contrib をインストールします。これには、
pg_upgrade
コマンドが含まれています。ご使用のPostgreSQLデータ領域(デフォルトでは
/var/lib/pgsql/data
)に十分な空き容量があることを確認します。容量が厳しい場合、次のSQLコマンドをデータベースごとに実行して、サイズを縮小します(長時間要する場合があります)。VACUUM FULL
以下のいずれかでPostgreSQLサーバを停止します。
root #
/usr/sbin/rcpostgresql
stopあるいは、
root #
systemctl stop postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
古いデータディレクトリの名前を変更します。
root #
mv
/var/lib/pgsql/data /var/lib/pgsql/data.old新規のデータベースインスタンスを初期化します。
initdb
を使用して手動で実行するか、PostgreSQLを起動、停止することで自動的に実行します。root #
/usr/sbin/rcpostgresql
startroot #
/usr/sbin/rcpostgresql
stopあるいは、
root #
systemctl start postgresql.serviceroot #
systemctl stop postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
古いバージョンの設定ファイルを変更している場合は、これらの変更を新しい設定ファイルに転送することを検討します。これは、
postgresql.auto.conf
、postgresql.conf
、pg_hba.conf
、およびpg_ident.conf
ファイルに影響する場合があります。これらのファイルの古いバージョンは/var/lib/pgsql/data.old/
にあり、新しいバージョンは/var/lib/pgsql/data
で見つけることができます。古い設定ファイルをコピーすることは推奨されないことに注意してください。コピーすることにより、新しいオプション、新しいデフォルト、および変更されたコメントが上書きされる場合があるためです。
ユーザの
postgres
としてマイグレーションプロセスを開始します。root #
su - postgres postgres >pg_upgrade
\ --old-datadir "/var/lib/pgsql/data.old" \ --new-datadir "/var/lib/pgsql/data" \ --old-bindir "/usr/lib/postgresql96/bin/" \ --new-bindir "/usr/lib/postgresql10/bin/"新しいデータベースインスタンスを次のいずれかを使用して開始します。
root #
/usr/sbin/rcpostgresql
startあるいは、
root #
systemctl start postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
マイグレーションが成功したかどうか確認します。テスト範囲はユースケースによって異なり、このステップを自動化する汎用ツールはありません。
すべての古いPostgreSQLパッケージと古いデータディレクトリを削除します。
root #
zypper
search -s postgresql96 | xargs zypper rm -uroot #
rm
-rf /var/lib/pgsql/data.old
データベースのアップグレード、または論理レプリケーションなどの代替方法の使用の詳細については、PostgreSQLの公式ドキュメント(https://www.postgresql.org/docs/10/upgrading.html)を参照してください。
3.7 仮想マシンゲストのシャットダウン #
お使いのマシンがKVMまたはXenのVMホストサーバとして機能している場合、アップデートの前には、実行中のすべてのVMゲストを正しくシャットダウンするようにします。そうでないと、更新後にゲストにアクセスできなくなる可能性があります。
3.8 SMTクライアントセットアップの調整 #
アップグレードするマシンがSMTサーバに対してクライアントとして登録されている場合は、次のことに注意してください。
ホストのclientSetup4SMT.sh
スクリプトのバージョンが最新であるかどうかを確認します。古いバージョンのSMTのclientSetup4SMT.sh
はSMT 12クライアントを管理できません。SMTサーバにソフトウェアパッチを定期的に適用している場合、常に最新バージョンのclientSetup4SMT.sh
を<SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh
で見つけることができます。
新しいバージョンのSUSE Linux Enterprise Serverへのマシンのアップグレードが失敗する場合は、手順 3.1の説明に従って、SMTサーバからマシンの登録を解除します。その後、アップグレードプロセスを再開します。
クライアントマシンにログインします。
次のステップは、クライアントの現在のオペレーティングシステムによって異なります。
SUSE Linux Enterprise 11の場合、次のコマンドを実行します。
tux >
sudo
suse_register -Etux >
sudo
rm -f /etc/SUSEConnecttux >
sudo
rm -rf /etc/zypp/credentials.d/*tux >
sudo
rm -rf /etc/zypp/repos.d/*tux >
sudo
rm -f /etc/zypp/services.d/*tux >
sudo
rm -f /var/cache/SuseRegister/*tux >
sudo
rm -f /etc/suseRegister*tux >
sudo
rm -f /var/cache/SuseRegister/lastzmdconfig.cachetux >
sudo
rm -f /etc/zmd/deviceidtux >
sudo
rm -f /etc/zmd/secretSUSE Linux Enterprise 12の場合、次のコマンドを実行します。
tux >
sudo
SUSEConnect --de-registertux >
sudo
SUSEConnect --cleanuptux >
sudo
rm -f /etc/SUSEConnecttux >
sudo
rm -rf /etc/zypp/credentials.d/*tux >
sudo
rm -rf /etc/zypp/repos.d/*tux >
sudo
rm -f /etc/zypp/services.d/*
SMTサーバにログインします。
すべてのクライアントの登録を一覧にして、クライアントが正常に登録解除されているかどうかを確認します。
tux >
sudo
smt-list-registrationsクライアントのホスト名がまだこのコマンドの出力に一覧表示されている場合は、最初の列からクライアントの
固有のID
を取得します。(クライアントは複数のIDで一覧表示されている場合があります。)このクライアントの登録を削除します。
tux >
sudo
smt-delete-registration -g UNIQUE_IDクライアントが複数のIDで一覧表示されている場合は、その固有のIDのそれぞれについてこのステップを繰り返します。
次のコマンドを再実行して、クライアントが正常に登録解除されているかどうかを確認します。
tux >
sudo
smt-list-registrations
3.9 ディスクスペース #
ソフトウェアは、バージョンが上がるたびに増加する傾向があります。そのため、更新する前に、使用可能名パーティションの容量を調べてください。ディスク容量が不足する可能性がある場合は、データをバックアップしてから、パーティションのサイズを変更するなどして、使用可能な容量を増やしてください。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。
更新手順の実行中に、YaSTは空きディスク容量を確認し、インストールで使用可能な容量を超える可能性がある場合は、ユーザに警告を表示します。その場合、更新を実行すると、「システムが使用できなくなる」ことがあります。操作の内容を(事前のテストによって)確実に把握している場合にのみ、この警告をスキップして更新を続行できます。
3.9.1 Btrfs以外のファイルシステムにおける空きディスク容量の確認 #
df
コマンドを使用して、使用可能なディスク容量を表示できます。たとえば、例3.1「df -h
の出力例」では、ルートパーティションは/dev/hda3
です(/
としてマウントされています)。
df -h
の出力例 #Filesystem Size Used Avail Use% Mounted on /dev/sda3 74G 22G 53G 29% / tmpfs 506M 0 506M 0% /dev/shm /dev/sda5 116G 5.8G 111G 5% /home /dev/sda1 44G 4G 40G 9% /data
3.9.2 Btrfsファイルシステムの空きディスク容量の確認 #
Btrfsファイルシステムでは、df
の出力は誤解を招く可能性があります。生データが割り当てる領域とは別に、Btrfsファイルシステムもメタデータ用の領域を割り当てて使用するからです。
その結果、まだ大量の領域を使用できるように見えても、Btrfsファイルシステムによって領域不足がレポートされることがあります。その場合、メタデータ用に割り当てられた領域はすべて使用されています。Btrfsファイルシステムでの使用済みおよび使用可能なスペースを確認する方法の詳細については、Book “ストレージ管理ガイド”, Chapter 1 “Linuxファイルシステムの概要”, Section 1.2.2.3 “空き領域の確認”を参照してください。詳細については、man 8 btrfs-filesystem
およびhttps://btrfs.wiki.kernel.org/index.php/FAQを参照してください。
マシンでBtrfsをルートファイルシステムとして使用している場合、十分な空き容量があることを確認します。すべてのマウント済みパーティションの使用可能なスペースを確認します。多くの場合、アップグレードには、新しいスナップショット用に、現在のルートファイルシステムと同じディスク容量が必要になります(/.snapshot
がない場合)。
効果が実証されている推奨事項は次のとおりです。
Btrfsを含めてすべてのファイルシステムで、大きなRPMをダウンロードし、インストールできるだけの空きディスク容量が必要です。古いRPMが使用している容量は、新しいRPMのインストール後にのみ解放されます。
スナップショットがあるBtrfsの場合、現在のインストールで使用している容量と同じだけの空き容量が最低でも必要です。現在のインストール環境の2倍の空き容量を確保することを推奨します。
十分な空き容量がない場合、
snapper
を使用して古いスナップショットを削除することができます。root #
snapper
listroot #
snapper
delete NUMBERしかし、すべてのケースでこの方法が役立つとは限りません。マイグレーションの前には、大半のスナップショットが占めている容量はごくわずかです。
3.10 SLE 12から15へAutoYaSTプロファイルの変更 #
AutoYaSTプロファイルのマイグレート方法については、Book “AutoYaST Guide”, を参照してください。
3.11 登録管理ツール(SMT)サーバのアップグレード #
SMTを実行しているサーバには特別なアップグレード手順が必要です。『Repository Management Tool Guide』のBook “Repository Mirroring Tool Guide”, Chapter 3 “Migrate from SMT to RMT”を参照してください。
3.12 カーネルのマルチバージョンサポートの一時的な無効化 #
SUSE Linux Enterprise Serverでは、/etc/zypp/zypp.conf
の各設定を有効にすることで、複数のカーネルバージョンをインストールできます。特定のサービスパックにアップグレードする場合、この機能のサポートを一時的に無効化する必要があります。更新が正常に完了したら、マルチバージョンサポートを再び有効にできます。マルチバージョンサポートを無効にするには、/etc/zypp/zypp.conf
の各行をコメント化します。結果は次のようになります。
#multiversion = provides:multiversion(kernel) #multiversion.kernels = latest,running
更新が正常に完了した後にこの機能を再アクティブ化するには、コメント記号を削除します。マルチバージョンサポートの詳細については、Book “導入ガイド”, Chapter 23 “複数バージョンのカーネルのインストール”, Section 23.1 “マルチバージョンサポートの有効化と設定”を参照してください。
3.13 IBM Zでのアップグレード #
IBM ZにインストールされたSUSE Linux Enterpriseをアップグレードするには、parmfileなどでカーネルパラメータUpgrade=1
を使用する必要があります。5.6項 「parmfile: システム設定の自動化」を参照してください。
3.14 IBM POWER: Xサーバの起動 #
SLES 12 for IBM POWERでは、ディスプレイマネージャがローカルのXサーバを起動しないように、デフォルトで設定されています。SLES 12 SP1ではこの設定は逆になっています。今は、ディスプレイマネージャはXサーバを起動します。
アップグレード時に問題が発生するのを避けるため、SUSE Linux Enterprise Serverの設定は自動的には変更されません。アップグレード後にディスプレイマネージャにXサーバを起動させたい場合は、/etc/sysconfig/displaymanager
でDISPLAYMANAGER_STARTS_XSERVER
の設定を次のように変更します。
DISPLAYMANAGER_STARTS_XSERVER="yes"
4 オフラインでのアップグレード #
この章では、インストールメディアからブートしたYaSTを使用して、既存のSUSE Linux Enterpriseインストール環境をアップグレードする方法を説明します。YaSTインストーラは、たとえばDVDから起動したり、ネットワーク上で起動したり、システムが存在するハードディスクから起動したりできます。
4.1 概念の概要 #
システムをアップグレードする前に、まず第3章 「アップグレードの準備」をお読みください。
システムをアップグレードするには、新規インストールの場合と同じようにインストールソースからブートします。ただし、ブート画面が表示されたときに、
を選択します( ではありません)。アップグレードは次の場所から開始できます。リムーバブルメディア. CD、DVD、USB大容量ストレージデバイスなどです。詳細については、4.2項 「インストールメディアからのアップグレードの開始」を参照してください。
ネットワークリソース. ローカルメディアからブートして、それぞれのネットワークインストールタイプを選択することも、PXEを介してブートすることもできます。詳細については、4.3項 「ネットワークソースからのアップグレードの開始」を参照してください。
4.2 インストールメディアからのアップグレードの開始 #
次の手順では、DVDからブートする方法を説明していますが、USB大容量ストレージデバイス上のISOイメージなど、他のローカルインストールメディアを使用することもできます。どのメディアとブート方法を選択するかは、システムアーキテクチャと、マシンに従来のBIOSまたはUEFIのどちらが搭載されているかによって決まります。
ブートメディアを選択して準備します。Book “導入ガイド”を参照してください。
SUSE Linux Enterprise Server 15 SP3用の統合インストーラDVDを挿入し、マシンを起動します。 画面が表示され、続けてブート画面が表示されます。
オプション: インストーラにネットワークソースからではなく、DVDからのみパッケージをインストールすることを強制するには、ブートオプション
media_upgrade=1
を追加します。ブートメニューで[アップグレード]を選択してシステムを起動します。
4.4項 「SUSE Linux Enterpriseのアップグレード」の説明に従って、アップグレードプロセスを進めます。
4.3 ネットワークソースからのアップグレードの開始 #
ネットワークインストールソースからアップグレードを開始する場合、以下の要件を満たしていることを確認してください。
- ネットワークインストールソース
ネットワークインストールソースがBook “導入ガイド”, Chapter 16 “ネットワークインストールソースをセットアップする”の記述どおりにセットアップされていること。
- ネットワーク接続およびネットワークサービス
インストールサーバとターゲットマシンの両方で、ネットワーク接続が正常に動作すること。必要なネットワークサービスは次のとおりです。
ドメインネームサービス
DHCP (PXEでブートする場合にのみ必要。IPはセットアップ時に手動で設定可能)
OpenSLP (オプション)
- ブートメディア
ブート可能なSUSE Enterprise DVD、ISOイメージ、または機能しているPXEセットアップ。PXEでのブートの詳細については、Book “導入ガイド”, Chapter 17 “ネットワークブート環境の準備”, Section 17.4 “ターゲットシステムにおけるPXEブートの準備”を参照してください。リモートサーバからのアップグレードの詳細については、Book “導入ガイド”, Chapter 11 “リモートインストール”を参照してください。
4.3.1 ネットワークインストールソース経由での手動アップグレード - DVDからのブート #
次の例では、DVDからブートする手順を説明していますが、USB大容量ストレージデバイス上のISOイメージなど、他のローカルインストールメディアを使用することもできます。ブート方式の選択し、メディアからシステムを起動する方法は、システムアーキテクチャ、およびマシンに従来型のBIOSまたはUEFIが装備されているかどうかによって異なります。詳しくは、以下のリンクを参照してください。
SUSE Linux Enterprise Server 15 SP3用の統合インストーラDVDを挿入し、マシンを起動します。 画面が表示され、続けてブート画面が表示されます。
使用するネットワークインストールソースのタイプ(FTP、HTTP、NFS、SMB、またはSLP)を選択します。通常、選択肢はF4キーを押すと表示されますが、ご使用のマシンに従来型のBIOSではなくUEFIが搭載されている場合は、パラメータを手動で調整しなければならない場合があります。詳細については、Book “導入ガイド”, Chapter 7 “ブートパラメータ”およびBook “導入ガイド”, Chapter 8 “インストール手順”を参照してください。
4.4項 「SUSE Linux Enterpriseのアップグレード」の説明に従って、アップグレードプロセスを進めます。
4.3.2 ネットワークインストールソース経由での手動アップグレード - PXEでのブート #
PXEブートを使用して、ネットワークインストールソースからアップグレードを実行するには、以下のようにします。
DHCPサーバの設定を調整してPXEブートに必要なアドレス情報を指定します。詳細については、Book “導入ガイド”, Chapter 17 “ネットワークブート環境の準備”, Section 17.1.1 “動的アドレス割り当て”を参照してください。
PXEブートに必要なブートイメージを保管するTFTPサーバを設定します。これにはSUSE Linux Enterprise Server 15 SP3用のインストーラDVDを使用するか、Book “導入ガイド”, Chapter 17 “ネットワークブート環境の準備”, Section 17.2 “TFTPサーバのセットアップ”の説明に従ってください。
ターゲットマシンにPXEブートとWake-on-LANを準備します。
ターゲットシステムのブートを開始し、VNCを使用してこのコンピュータで実行中のインストールルーチンにリモートで接続します。詳細については、Book “導入ガイド”, Chapter 11 “リモートインストール”, Section 11.3 “VNCによるインストールの監視”を参照してください。
4.4項 「SUSE Linux Enterpriseのアップグレード」の説明に従って、アップグレードプロセスを進めます。
4.4 SUSE Linux Enterpriseのアップグレード #
システムのアップグレード前に、第3章 「アップグレードの準備」をご覧ください。自動マイグレーションを実行するには、次の手順に従います。
アップグレードするシステムがSUSEカスタマーセンターに登録されている場合は、次の手順の間にインターネットに接続されていることを確認してください。
ブートした後(インストールメディアまたはネットワーク、いずれかの方法による)、ブート画面の
エントリを選択します。警告: 選択を間違えるとデータを失う場合があります。この時点で
を選択していることを確認してください。間違って を選択すると、データパーティションが新しいインストールで上書きされます。YaSTはインストールシステムを起動します。
YaSTは、インストール済みのSUSE Linux Enterpriseシステムのパーティションをチェックします。
YaSTは、選択したパーティションをマウントし、アップグレードした製品の使用許諾契約を表示します。続行するには、使用許諾契約を受諾します。
カスタムリポジトリがある場合は、次の2つの選択肢があります。
リポジトリを削除済み状態のままにする。このリポジトリからインストールされたソフトウェアはアップグレード中に削除されます。新しいリリースに一致するリポジトリのバージョンが使用できない場合はこの方法を使用します。
リポジトリが新しいリリースに一致する場合はアップデートして有効にする。リストでリポジトリをクリックしてそのURLを変更し、
をクリックします。 が に設定されるまでチェックして、リポジトリを有効にします。
システムが不安定であるか、まったく機能しない場合があるため、以前のリリースのリポジトリを保持しないでください。
をクリックして続行します。次の手順は、アップグレードしたシステムがSUSEカスタマーセンターに登録されているかどうかにより異なります。
システムがSUSEカスタマーセンターに登録されていない場合、YaSTには2つめのインストールメディアである、SLE-15-SP2-Full-ARCH-GM-media1.isoイメージを使用することを提案するポップアップメッセージが表示されます。
このメディアがない場合、登録せずにシステムをアップグレードすることはできません。
システムがSUSEカスタマーセンターに登録されている場合、可能性のあるマイグレーションターゲットとサマリが表示されます。
リストからマイグレーションターゲットを1つ選択し、
で続行します。
次のダイアログで、追加のインストールメディアをオプションで追加できます。追加のインストールメディアがある場合は、
オプションを有効にして、メディアタイプを指定します。アップグレードの
を確認します。すべての設定を希望どおりに完了したら、
をクリックして、インストールおよび削除の手順を開始します。ヒント: SMTクライアントでのアップグレードの失敗アップグレードするマシンがSMTクライアントで、アップグレードが失敗する場合は、手順3.1「SMTサーバからSUSE Linux Enterpriseクライアントの登録を解除する」を参照して、後でアップグレード手順を再開してください。
アップグレードプロセスが正常に終了した後で、4.4.1項 「アップグレード後のチェック」の説明に従って、アップグレード後のチェックを実行します。
4.4.1 アップグレード後のチェック #
「孤立したパッケージ」がないか確認します。アップグレード手順の実行中に、パッケージの名前が変更されたり、削除されたり、マージされたり、分割されたりする場合があります。その結果、特定のパッケージが孤立してサポートされなくなる可能性があります。孤立したパッケージは、自動的に削除されません。次のコマンドで、これらのリストを表示できます。
tux >
zypper packages --orphaned --unneededリストを使用して、まだ必要なパッケージと、安全に削除できるパッケージを決定します。
*.rpmnew
および*.rpmsave
ファイルがないか確認して、そのコンテンツを調べ、できれば必要な変更をマージしてください。アップグレードに設定ファイルの上書きではなくデフォルトの設定ファイルへの変更が含まれる場合、パッケージはこれらのファイルタイプのいずれかを書き込みます。*.rpmnew
に新しいデフォルトの設定が含まれ、元のファイルがそのまま残りますが、*.rpmsave
は新しいデフォルトファイルによって置き換えられた元の設定のコピーです。ファイルシステム全体で
*.rpmnew
および*.rpmsave
ファイルを検索する必要がありません。最も重要なファイルは/etc
ディレクトリに格納されています。それらを一覧表示するには、次のコマンドを使用します。tux >
find /etc -print | egrep "rpmnew$|rpmsave$"
4.5 AutoYaSTを使用したアップグレード #
アップグレードプロセスを自動的に実行できます。詳細については、Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.10 “Upgrade”を参照してください。
4.6 SUSE Managerを使用したアップグレード #
SUSE Managerは、SUSE Linux Enterpriseクライアントに対するアップデート、パッチ、およびセキュリティ修正を提供するためのサーバソリューションです。これには、一連のツールと、管理タスク用のWebベースのユーザインタフェースが付属しています。SUSE Managerの詳細については、https://www.suse.com/products/suse-manager/を参照してください。
SUSE Managerを使用して、システムのアップグレードを実行できます。統合されたAutoYaST技術を使用して、1つのメジャーバージョンから次のバージョンにアップグレードが可能です。
マシンがSUSE Managerによって管理されている場合は、SUSE Managerドキュメントの説明に従ってアップデートしてください。「Client Migration」の手順については、https://documentation.suse.com/suma/で入手可能な『SUSE Manager Upgrade Guide』を参照してください。
4.7 ロールバック後の登録状態の更新 #
サービスパックのアップグレードを実行する場合は、登録サーバで設定を変更して、新しいリポジトリへのアクセスを提供する必要があります。アップグレードプロセスが中断されたり、(バックアップまたはスナップショットからの復元によって)取り消されたりすると、登録サーバ上の情報とシステムの状態との一貫性が損なわれます。これにより、更新ポジトリにアクセスできなくなったり、クライアントで間違ったリポジトリが使用されたりすることがあります。
Snapperによってロールバックが実行される場合、システムは登録サーバに通知し、ブートプロセス中に正しいリポジトリへのアクセスが設定されるようにします。システムが別の方法で復元された場合や、登録サーバとの通信に失敗した場合は、クライアント上でロールバックを手動でトリガします。ロールバックを手動でトリガする状況の例として、ネットワークの問題のため、サーバにアクセスできなかった場合があります。ロールバックを実行するには、次のコマンドを実行します。
tux >
sudo
snapper
rollback
次のコマンドを使用して、システムに正しいリポジトリが設定されていることを常に確認することをお勧めします。特にサービスの更新後は必ず確認してください。
tux >
sudo
zypper
ref -s
この機能は rollback-helper パッケージの次のアップデートで加える変更は保存されません。
4.8 システムの登録 #
アップグレードを実行する前にシステムが登録されていない場合は、YaSTの
モジュールを使用していつでもシステムを登録できます。ご使用のシステムを登録すると以下の利点があります。
サポート利用資格
セキュリティアップデートとバグフィックスの入手
SUSEカスタマーセンターへのアクセス
YaSTを起動し、
› を選択して、 ダイアログを開きます。各自または各自の組織が登録の管理に使用しているSUSEアカウントに関連付けられたhttps://scc.suse.com/)でアカウントを作成します。
アドレスを指定します。SUSEアカウントをまだ作成していない場合は、SUSEのカスタマセンターのホームページ(を入力します。
に添付されている登録コードネットワーク上で1台または複数台のローカル登録サーバが使用可能な場合は、リストに示されたサーバのうちいずれかを選択できます。
登録を開始するには、
で続行します。正常に登録されると、YaSTにより、システムで使用可能な拡張機能、アドオン、およびモジュールが表示されます。これらを選択してインストールするには、Book “導入ガイド”, Chapter 22 “モジュール、拡張機能、サードパーティ製アドオン製品のインストール”, Section 22.1 “オンラインチャネルからのモジュールと拡張機能のインストール”に進みます。
5 オンラインでのアップグレード #
SUSEは、動作中のシステムを新しいサービスパックにアップグレードするための直感的なグラフィカルツールとシンプルなコマンドラインツールを提供します。これらのツールは、サービスパックの「ロールバック」などをサポートしています。この章では、これらのツールを使用してサービスパックのアップグレードを実行する方法を順を追って説明します。
5.1 概念の概要 #
SUSEは、SUSE Linux Enterpriseファミリ用の新しいサービスパックを定期的にリリースしています。お客様が新しいサービスパックに容易にマイグレートしてダウンタイムを最小限に抑えることができるよう、SUSEはシステム実行中のオンラインマイグレーションをサポートしています。
SLE 12から、YaST WagonはYaSTマイグレーション(GUI)およびZypperマイグレーション(コマンドライン)に置き換えられました。これには以下のような利点があります。
最初のRPMが更新されるまで、システムは常に定義済みの状態
最初のRPMが更新されるまでは、キャンセルが可能.
エラーが発生した場合、簡単に回復.
システムツールを介して「ロールバック」を実行可能 - バックアップや復元は必要ない
アクティブなすべてのリポジトリを使用.
サービスパックをスキップ可能
オンラインマイグレーションは、サービスパック間のマイグレーションでのみサポートされています。オンラインマイグレーションは、新しいメジャーリリースへのアップグレードではサポートされていません。詳細については、第1章 「アップグレードパスと方法」を参照してください。
新しいメジャーリリースにアップグレードする場合は、オフラインマイグレーションを使用します。詳細については、第4章 「オフラインでのアップグレード」を参照してください。
アップグレードするシステムがSUSE Managerクライアントの場合は、YaSTオンラインマイグレーションやzypper migration
ではアップグレードできません。代わりに、「Client Migration」手順を使用してください。『
SUSE Manager Upgrade Guide』で説明されています。
5.2 サービスパックのマイグレーションのワークフロー #
サービスパックのマイグレーションは、YaST、zypper
、またはAutoYaSTにより実行できます。
サービスパックのマイグレーションを開始する前に、SUSEカスタマーセンターまたはローカルRMTサーバでシステムを登録する必要があります。SUSE Managerも使用できます。
どの方法を使用する場合も、サービスパックのマイグレーションは次の手順で構成されます。
登録システムで、マイグレーションターゲットの候補を見つけます。
マイグレーションターゲットを1つ選択します。
新しいリポジトリを要求して有効にします。
マイグレーションを実行します。
マイグレーションターゲットのリストは、インストールおよび登録されている製品に応じて異なります。新しいSPがまだ利用可能になっていない拡張機能がインストールされている場合、マイグレーションターゲットが提供されない可能性があります。
ホストで使用可能なマイグレーションターゲットのリストは、常にSUSEカスタマーセンターから取得され、インストールされている製品または拡張機能に応じて異なります。
5.3 サービスパックのマイグレーションのキャンセル #
サービスパックのマイグレーションは、マイグレーションプロセスの特定の段階でのみキャンセルできます。
パッケージのアップグレードが開始されるまで、システムには、サービスやリポジトリなどの最小限の変更しか加えられません。以前の状態に戻すには、
/etc/zypp/repos.d/*
を復元します。パッケージのアップグレードが開始された後は、Snapperスナップショットを使用して以前の状態に戻すことができます(Book “管理ガイド”, Chapter 7 “Snapperを使用したシステムの回復とスナップショット管理”を参照してください)。
マイグレーションターゲットが選択された後、SUSEカスタマーセンターによってリポジトリデータが変更されます。この状態を手動で元に戻すには、
SUSEConnect
--rollback
を使用します。
5.4 オンラインマイグレーションツール(YaST)を使用したアップグレード #
YaSTを使用してサービスパックのマイグレーションを実行するには、
ツールを使用します。デフォルトでは、YaSTはサードパーティリポジトリからパッケージをインストールしません。パッケージがサードパーティリポジトリからインストールされている場合、YaSTは、SUSEから提供されている同じパッケージによってパッケージが置き換えられるのを防ぎます。サービスパックのマイグレーションの実行時に、YaSTは推奨パッケージをすべてインストールします。特にカスタム最小インストールの場合、これによってシステムのインストールサイズが大幅に増加することがあります。
このデフォルトの動作を変更し、必要なパッケージのみを許可するには、/etc/zypp/zypp.conf
で、solver.onlyRequires
オプションを調整します。
solver.onlyRequires = true
また、ファイル/etc/zypp/zypper.conf
を編集して、installRecommends
オプションを変更します。
installRecommends=false
これにより、パッチや新しいパッケージのインストールなど、すべてのパッケージ操作の動作が変更されます。1回の起動に対してのみZypperの動作を変更するには、パラメータ--no-recommends
をコマンドラインに追加します。
サービスパックのマイグレーションを開始するには、次の手順を実行します。
登録サーバ上の未使用の拡張機能をすべて無効にして、将来、依存関係の競合が発生が発生するのを防ぎます。拡張機能を覚えていなくても、後でYaSTによって未使用の拡張機能リポジトリが検出され、無効にされます。
更新するマシンで実行されているGNOMEセッションにログインしている場合は、テキストコンソールに切り替えます。GNOMEセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、GNOMEでVNCセッションを実行している場合を除きます)。
YaSTオンラインアップデートを実行して、システム用の最新のパッケージのアップデートを取得します。
パッケージ yast2-migration およびその依存関係をインストールします(YaSTの › )。
YaSTを再起動します。再起動しないと、新しくインストールしたモジュールがコントロールセンターに表示されません。
YaSTで、SUSE Linux Enterprise Serverのバージョンによって、このモジュールは または の下にあります)。可能性のあるマイグレーションターゲットと概要がYaSTによって表示されます。システムで使用可能なマイグレーションターゲットが複数ある場合は、リストから1つを選択します。
を選択します(アップグレードするリストからマイグレーションターゲットを1つ選択し、
で続行します。マイグレーションツールによってアップデートリポジトリが提供される場合は、
で続行することをお勧めします。[Online Migration (オンラインマイグレーション)]ツールにより、DVDまたはローカルサーバから提供されている古いリポジトリが検出される場合は、それらを無効にすることを強くお勧めします。古いリポジトリは以前のSPのものです。SUSEカスタマーセンターまたはRMTからの古いリポジトリは、すべて自動的に削除されます。
概要を確認し、
をクリックしてマイグレーションを続行します。 を選択して確認します。マイグレーションが正常に完了したら、システムを再起動します。
5.5 Zypperによるアップグレード #
Zypperを使用してサービスパックのマイグレーションを実行するには、コマンドラインツールzypper
migration
をパッケージ
zypper-migration-pluginをインストールします。
サービスパックのマイグレーションの実行時に、YaSTは推奨パッケージをすべてインストールします。特にカスタム最小インストールの場合、これによってシステムのインストールサイズが大幅に増加することがあります。
このデフォルトの動作を変更し、必要なパッケージのみを許可するには、/etc/zypp/zypp.conf
で、solver.onlyRequires
オプションを調整します。
solver.onlyRequires = true
また、ファイル/etc/zypp/zypper.conf
を編集して、installRecommends
オプションを変更します。
installRecommends=false
これにより、パッチや新しいパッケージのインストールなど、すべてのパッケージ操作の動作が変更されます。1回の起動に対してのみZypperの動作を変更するには、パラメータ--no-recommends
をコマンドラインに追加します。
サービスパックのマイグレーションを開始するには、次の手順を実行します。
更新するマシンで実行されているGNOMEセッションにログインしている場合は、テキストコンソールに切り替えます。GNOMEセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、GNOMEでVNCセッションを実行している場合を除きます)。
SUSE Linux Enterpriseマシンをまだ登録していない場合は登録します。
tux >
sudo
SUSEConnect
--regcode YOUR_REGISTRATION_CODEマイグレーションを開始します。
tux >
sudo
zypper migration
マイグレーションプロセスに関する注記
システムで使用可能なマイグレーションターゲットが複数ある場合は、Zypperでリストから1つを選択できます。これはSPを1つまたは複数スキップするのと同じことです。基本製品(SLES、SLED)のオンラインマイグレーションを使用できるのは、メジャーバージョンのSP間のみであることに注意してください。
デフォルトでは、Zypperは、
zypper
dup
に渡されるオプション--no-allow-vendor-change
を使用します。パッケージがサードパーティリポジトリからインストールされている場合、このオプションにより、SUSEから提供されている同じパッケージによって該当するパッケージが置き換えられるのを防ぎます。Zypperにより、DVDまたはローカルサーバから提供されている古いリポジトリが検出される場合は、それらを無効にすることを強くお勧めします。SUSEカスタマーセンターまたはRMTからの古いリポジトリは自動的に削除されます。
すべての変更内容を確認します。特に、削除されるパッケージに注意してください。「
y
」と入力して続行します(アップグレードするパッケージの正確な数はシステムによって異なる可能性があります)。266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch. Overall download size: 285.1 MiB. Already cached: 0 B After the operation, additional 139.8 MiB will be used. Continue? [y/n/? shows all options] (y):
シェルをスクロールするには、Shift–Page ↑ またはShift–Page ↓ キーを使用します。
マイグレーションが正常に完了したら、システムを再起動します。
5.6 プレーンZypperによるアップグレード #
インターネットや登録サーバにアクセスできないため、システムが登録されていない場合、YaSTマイグレーションまたはzypper migration
を使用して新しいサービスパックに移行することはできません。この場合でも、プレーンZypperやいくつかの手動での対話操作により新しいサービスパックに移行することができます。
新しいサービスパックへのこのマイグレーションパスは、インターネットや登録サーバにアクセスできない未登録システムに「のみ」サポートされています。たとえば、特別に保護されたネットワーク内のマシンの場合などです。システムが登録済みである場合は、YaSTまたはZypperマイグレーションを使用してください。
このマイグレーションパスでは、移行するマシンによってアクセス可能な場所に新しいサービスパックのインストールソースを提供する必要があります。これは、たとえば、RMTサーバやSLPサーバをセットアップすることによって実現できます。
システムがインストール済みの製品バージョンの最新のアップデートリポジトリにアクセスできる必要もあります。
移行するマシンで実行されているグラフィカルセッションにログインしている場合は、そのセッションをログアウトして、テキストコンソールに切り替えます。グラフィカルセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、XでVNCセッションを実行している場合を除きます)。
SUSE Linux Enterpriseの古いリポジトリを使用してパッケージ管理ツールを更新します。
tux >
sudo
zypper
patch --updatestack-only現在リポジトリが割り当てられていないパッケージ(孤立したパッケージ)のリストを取得します。これらのパッケージは移行されず、マイグレーション後に動作する保証はありません(依存する他のパッケージは互換性がなくなったため変更されている可能性があるため)。リストを取得するには、次のコマンドを実行します:
tux >
sudo
zypper packages --orphanedリストを注意深く確認して、必要なくなったすべての孤立パッケージを削除します。残りのすべての孤立パッケージをメモしてください。後で比較用に必要となります。
次のコマンドを実行して、システムが現在サブスクライブしているすべてのリポジトリのリストを取得します。
tux >
sudo
zypper repos -u製品バージョン番号が
15-SP3
となるように、各リポジトリのURLをアップデートします。たとえば、リポジトリのURLが、http://rmt.example.com/repo/SUSE/Products/SLE-15-SP2-Product-SLES/x86_64/product/
の場合は、次のように変更します。
http://rmt.example.com/repo/SUSE/Products/SLE-15-SP3-Product-SLES/x86_64/product/
これは、有効になっているすべてのリポジトリで実行される必要があります。また、後でアクティブ化するときにシステム内に間違ったインストールソースが存在しないように、現在無効になっているリポジトリに対してもこの操作を行うことを検討してください。
リポジトリURLを変更するには、次のオプションがあります。
Zypperの使用。次のコマンドを実行して、古いリポジトリを削除します。
tux >
sudo
zypper removerepo OLD_REPO_ID削除後、対応する新しいリポジトリを次のコマンドを実行して追加します。
tux >
sudo
zypper addrepo -f URL NAME-15-SP3/etc/zypp/repos.d
でリポジトリ設定ファイルを編集する。各リポジトリは1つの設定ファイルで表されます。各ファイルで、baseurl
パラメータの値を変更する必要があります。
zypper repos -u
を実行して変更を確認し、次のコマンドを実行してリポジトリをアップデートします。tux >
sudo
zypper refresh -f -sリポジトリのアップデートに失敗した場合は、間違ったURLを入力していないか再確認します。問題が修正できない場合は、失敗したリポジトリを無効にすることをお勧めします。
すべてのリポジトリが正常に設定された場合は、次のコマンドを再度実行して、
tux >
sudo
zypper refresh -f -s「すべて」のリポジトリが最新であることを確認します。
マイグレーションを開始する前に、まずテストランを実行することをお勧めします。
tux >
sudo
zypper dup -D --no-allow-vendor-change --no-recommendsパラメータ
-D
は、実際にシステムを変更せずにマイグレーションをシミュレートする、ドライランを実行します。問題が発生する場合は、修正してから続行してください。テストランが成功した場合は、次のコマンドを実行して実際のマイグレーションを実行します:tux >
sudo
zypper dup --no-allow-vendor-change --no-recommends-no-allow-vendor-change
は、サードパーティRPMが基本システムからRPMを上書きしないようにします。--no-recommends
オプションは、初期インストール時に選択解除したパッケージが再び追加されないようにします。マイグレーションが終了して、システムが新しいサービスパックバージョンで起動したら、孤立パッケージのチェックを再度実行します。
tux >
sudo
zypper packages --orphaned新しいリストとマイグレーションを開始する前に生成されたリストを比較します。リストに新しいパッケージが表示された場合は、新しいサービスパックの別のモジュールに移動されたことが原因である可能性があります。以前のインストールにそのモジュールがなかった場合、このパッケージはアップデートされていません。
https://scc.suse.com/packagesでパッケージが属するモジュールを確認できます。
zypper addrepo
またはYaSTソフトウェアリポジトリモジュールを使用して、不足しているモジュールを追加し、次のコマンドを実行して後で孤立パッケージをアップデートします。tux >
sudo
zypper install --no-recommends LIST OF PACKAGES新しいサービスパックに正常に移行しました。
5.7 サービスパックのロールバック #
サービスパックの有効性が認められない場合は、SUSE Linux Enterpriseシステムをサービスパックのマイグレーションが開始される前の状態に戻すことができます。このためには、スナップショットが有効なBtrfsルートパーティションであることが前提条件です(これはSLES 12以降のデフォルトです)。詳細についてはBook “管理ガイド”, Chapter 7 “Snapperを使用したシステムの回復とスナップショット管理”を参照してください。
すべてのSnapperスナップショットのリストを取得します。
tux >
sudo
snapper list出力を確認して、サービスパックのマイグレーションの開始直前に作成されたスナップショットを見つけます。列
には対応するステートメントが含まれており、スナップショットには列 にimportant
というマークが付いています。列 のスナップショット番号と、列 の日付を覚えます。システムを再起動します。ブートメニューから15 SP3で始まるエントリを選択して起動します。
を選択して、前の手順で覚えた日付と番号が付いたスナップショットを選択します。2番目のブートメニュー(スナップショットのブートメニュー)がロードされます。SLESシステムが以前の状態で起動し、システムパーティションは読み込み専用でマウントされます。
root
としてログインし、正しいスナップショットを選択しているかどうかを確認します。また、すべてが正常に機能することも確認します。ルートファイルシステムは読み込み専用でマウントされるため、機能の制限が適用される場合があることに注意してください。問題がある場合、または間違ったスナップショットをブートした場合は、再起動して、ブート元として別のスナップショットを選択します。この時点では、恒久的な変更は加えられていません。スナップショットが正しく、正常に機能する場合、次のコマンドを実行して変更を確定します。
tux >
sudo
snapper rollback続いて再起動を行います。ブート画面で、デフォルトのブートエントリを選択して、復元されたシステムで再起動します。
リポジトリの設定が適切にリセットされているかどうかを確認します。さらに、すべての製品が適切に登録されているかどうかも確認します。いずれかが間違っていると、後でシステムを更新しようとしてもできなかったり、間違ったパッケージリポジトリを使用してシステムが更新されたりすることがあります。
次の手順を開始する前に、システムがインターネットにアクセスできることを確認してください。
次のコマンドを実行して、サービスとリポジトリを更新します。
tux >
sudo
zypper ref -fs次のコマンドを実行して、アクティブなリポジトリのリストを取得します。
tux >
sudo
zypper lrこのコマンドの出力を入念に確認します。更新対象として追加したサービスとリポジトリが一覧にされていてはなりません。たとえば、SLES 15 SP3からSLES15 GAへのマイグレーションをロールバックする場合、
SLES15-SP3
のリポジトリではなく、SLES15-GA
のリポジトリがリストに含まれている必要があります。間違ったリポジトリが一覧にされている場合は削除し、必要に応じて、製品またはサービスパックのバージョンに一致するバージョンに置き換えます。サポートされるマイグレーションパスのリポジトリのリストについては、2.3項 「モジュールの依存関係とライフサイクル」を参照してください。(リポジトリは自動的に更新されるため、手動での操作は必要ありませんが、確認して必要な修正を行うことがベストプラクティスです。)
最後に、次のコマンドを実行して、インストールされているすべての製品の登録状態を確認します。
tux >
sudo
SUSEConnect --statusすべての製品が「
登録されています
」とレポートされる必要があります。そうなっていない場合は、次のコマンドを実行して登録を修復します。tux >
sudo
SUSEConnect --rollback
以上で、システムは正常にサービスパックのマイグレーション開始直前にキャプチャされた状態に戻りました。
5.8 SUSE Managerを使用したアップグレード #
SUSE Managerは、SUSE Linux Enterpriseクライアントに対するアップデート、パッチ、およびセキュリティ修正を提供するためのサーバソリューションです。これには、一連のツールと、管理タスク用のWebベースのユーザインタフェースが付属しています。SUSE Managerの詳細については、https://www.suse.com/products/suse-manager/を参照してください。
マイグレーションにより、3つのメジャーバージョン内で特定のサービスパック(SP)を別のSPにマイグレートできます(たとえば、SLES 15 GAからSLES 15 SP1)。
マシンがSUSE Managerによって管理されている場合は、SUSE Managerドキュメントの説明に従ってアップデートしてください。「Client Migration」の手順については、https://documentation.suse.com/suma/で入手可能な『SUSE Manager Upgrade Guide』を参照してください。
5.9 openSUSE LeapからSUSE Linux Enterprise Serverへのアップグレード #
openSUSE LeapインストールをSUSE Linux Enterprise Serverにアップグレードすることができます。手順は5.4項 「オンラインマイグレーションツール(YaST)を使用したアップグレード」で説明したものと同様ですが、いくつかの追加の手順が必要となります。運用システムでこの手順を実行する前に、運用環境のセットアップを複製するテストシステムでまず実行することをお勧めします。
どのバージョンのopenSUSE Leapがマイグレーションに対応しているかを確認するには、1.2項 「SLES 15 SP3へのサポートされているアップグレードパス」を参照してください。
openSUSEはSUSE Linux Enterprise Serverよりも多くのパッケージを提供します。追加パッケージのほとんどはSUSE Package Hubから入手可能であり、マイグレートされます。SUSE Package Hubから入手できない追加パッケージは、マイグレーション後にアップデートを受けられなくなるため、後で削除する必要があります。
システムを動作させるために必要なすべてのパッケージが、SUSE Linux Enterprise ServerとSUSE Package Hubのリポジトリから入手できることを確認してください。SUSE Package Hubの詳細については、Book “導入ガイド”, Chapter 22 “モジュール、拡張機能、サードパーティ製アドオン製品のインストール”, Section 22.3 “SUSE Package Hub”を参照してください。
openSUSE LeapからSUSE Linux Enterprise Serverにマイグレートするには、以下の手順に従ってください。
たとえば、Ctrl–Alt–F1を押して、TTYに切り替えます。
root
としてログインします。yast2- registration および rollback-helper パッケージをインストールします。
root #
zypper in yast2-registration rollback-helper
rollback-helper
サービスを有効化します。root #
systemctl enable rollback
SUSEカスタマーセンターにシステムを登録します。
root #
yast2 registration
マイグレーションを実行します。
root #
yast2 migration
パッケージが競合する場合は、YaSTが対処法のリストを表示するので、そこから選択します。
孤立したパッケージを削除します。
root #
zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
システムを再起動します。
root #
reboot
これで、SUSE Linux Enterprise Serverにシステムを正常にマイグレートできました。
マイグレーション後に問題が生じた場合は、サービスパックのアップグレードと同様にマイグレーションを元に戻すことができます。処理手順の詳細については、 5.7項 「サービスパックのロールバック」を参照してください。
6 ソースコードのバックポート #
SUSEはバックポートを広い範囲で使用しています。バックポートとは、ソフトウェアの最新の修正や機能をリリース済みのSUSE Linux Enterpriseパッケージにマイグレートすることです。この章では、SUSE Linux Enterpriseソフトウェアパッケージの機能とセキュリティを判断するためにバージョン番号を比較しても当てにならない可能性がある理由について説明します。この章では、SUSEがどのようにしてシステムソフトウェアをセキュアで最新の状態に保ちつつ、SUSE Linux Enterprise製品上でアプリケーションソフトウェアの互換性を維持しているかについても説明します。さらに、公表されているセキュリティ上の問題のうち、ご使用のSUSE Linux Enterpriseシステムソフトウェアでどれが実際に対応済みかを確認する方法、およびご使用のソフトウェアの最新ステータスを確認する方法を学ぶこともできます。
6.1 バックポートを行う理由 #
アップストリームの開発者は、自分が開発するソフトウェアを前進させることを念頭に置いています。多くの場合、バグの修正と新機能の導入が組み合わせられますが、その新機能は詳細なテストをまだ受けていないために、新しいバグを生み出す可能性があります。
配布物の開発者としては、次のものを見分けることが重要です。
バグ修正(機能を中断する限定的な可能性がある)。
変更(既存の機能を中断する可能性がある)。
多くの場合、パッケージがリリースされた配布物の一部になったら、配布物の開発者はアップストリームでのすべての変更を追うことはしません。通常は、最初にリリースされたアップストリームバージョンから離れずに、アップストリームの変更に基づいてパッチを作成してバグを修正します。こうした一連の処理はバックポートと呼ばれています。
一般的に、配布物の開発者が新しいバージョンのソフトウェアを導入するのは、次の2つの場合のみです。
パッケージとアップストリームバージョンの変更内容の差があまりに大きくなり、バックポートが不可能になってしまった場合。
本質的に経年劣化するソフトウェア(マルウェア対策ソフトウェアなど)。
SUSEでは、エンタープライズソフトウェアに対する数多くの考慮事項のバランスをうまく取るために、広い範囲でバックポートを使用しています。こうした考慮事項のうち最も重要なものは次のとおりです。
SUSEのエンタープライズ製品上で使用する製品を構築する際にソフトウェアベンダーが信頼することのできる安定したインタフェース(API)を提供すること。
SUSEのエンタープライズ製品のリリースで使用するパッケージが、単体としてもエンタープライズ製品全体の一部としても、最高品質であり、完全にテスト済みであることを確認すること。
SUSEのエンタープライズ製品に対するその他のベンダーによるさまざまな証明書を維持すること(OracleまたはSAP製品の証明書など)。
SUSEの開発者が、リリース全体に薄く広く注意を拡散させるのではなく、次の製品バージョンの開発に集中できるようにすること。
特定のエンタープライズ向けリリースの内容の明確性を保ち、サポートがそのリリースについて正確かつタイムリーな情報を提供できるようにすること。
6.2 バックポートを行わない理由 #
一般的なポリシールールとしては、当社のエンタープライズ製品に、パッケージの新しいアップストリームバージョンは導入されないことになっています。ただしこのルールは絶対的なものではありません。特定のタイプのパッケージ(特にウィルス対策ソフトウェア内)では、品質確保の観点から選ばれた保守的なアプローチよりも、セキュリティに関する考慮事項の方が重視されます。こうしたクラスのパッケージでは、時として、エンタープライズ製品ラインのリリース済みバージョンに、新しいバージョンが導入されることがあります。
その他のタイプのパッケージについても、バックポートではなく新しいバージョンの導入が選択される場合があります。バックポートの作成が経済的に不可能な場合や、新しいバージョンの導入に対する非常に妥当な技術的な理由が存在する場合などがこれに該当します。
6.3 バージョン番号の解釈に対するバックポートの意味 #
バックポートが実行されているために、SUSEパッケージに特定の問題の修正が含まれているのか、または特定の機能が追加されているのかを、バージョン番号を単純に比較して判断することはできません。バックポートでは、SUSEパッケージのバージョン番号のアップストリーム部分は、単にSUSEパッケージの基となっているアップストリームバージョンを示しているだけです。ここには、対応するアップストリームリリースには存在しないけれどもSUSEパッケージにはバックポートされている修正や機能が含まれている可能性があります。
バックポートが関係する場合にバージョン番号のこの限られた値が問題を引き起こす可能性がある、1つの特定の領域として、セキュリティスキャンツールの使用が挙げられます。セキュリティの脆弱性スキャンツール(または、それらのツールによる特定のテスト)の中には、単にバージョン情報のみに基づいて機能するものがあります。したがって、これらのツールおよびテストでは、バックポートが関係している場合に「false positives」(ソフトウェアが脆弱であると誤って断定されてしまうこと)が生成される傾向があります。セキュリティスキャンツールでレポートを評価する場合は、エントリがバージョン番号に基づくものなのか、それとも実際の脆弱性テストに基づくものなのかを、常に確認してください。
6.4 修正されたバグおよびバックポート機能の確認 #
バックポートされたバグ修正や機能に関する情報が保存されている場所は数多くあります。
パッケージの変更ログ:
tux >
rpm -q --changelog name-of-installed-packagetux >
rpm -qp --changelog packagefile.rpmパッケージの変更履歴を簡単にドキュメント化した出力です。
パッケージの変更ログには、
bsc#1234
(「Bugzilla Suse.Com」)などのエントリが含まれています。これは、SUSEのBugzillaトラッキングシステムのバグ、または他のバグトラッキングシステムへのリンクを示しています。機密保護ポリシーにより、ユーザがこうした情報のすべてにアクセスできるわけではありません。パッケージには、SUSEパッケージに固有の一般的な概要情報を含む
/usr/share/doc/PACKAGENAME/README.SUSE
ファイルが格納されている場合もあります。RPMソースパッケージには、通常のバイナリRPMを個別のファイルとして構築するときに適用されたパッチが含まれます。これらのファイルは、ソースコードの解読に精通していれば解釈することができます。SUSE Linux Enterpriseソフトウェアのソースのインストールについては、Book “管理ガイド”, Chapter 6 “コマンドラインツールによるソフトウェアの管理”, Section 6.1.3.5 “ソースパッケージのインストールまたはダウンロード”を参照してください。SUSE Linux Enterpriseにおけるパッケージの構築については、Book “管理ガイド”, Chapter 6 “コマンドラインツールによるソフトウェアの管理”, Section 6.2.5 “ソースパッケージのインストールとコンパイル”を参照してください。SUSE Linux Enterpriseのソフトウェアパッケージの構築に関する詳細については、「Maximum RPM」ドキュメントを参照してください。
セキュリティ上のバグ修正については、SUSEのセキュリティ告知を参照してください。これらは、
CAN-2005-2495
などの標準化された名前でバグを表すことがよくあります。こうした名前は、Common Vulnerabilities and Exposures (CVE)プロジェクトによって管理されています。
A GNU licenses #
This appendix contains the GNU Free Documentation License version 1.2.
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 non-commercially, 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 https://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.