目次にジャンプ
documentation.suse.com / アップグレードガイド
SUSE Linux Enterprise Server 15 SP3

アップグレードガイド

このガイドでは、SUSE Linux Enterprise Serverのアップグレードについて説明します。SUSE Linux Enterprise Serverを他のSLE製品や拡張機能の基本システムとして使用している場合は、それらの製品ドキュメントも参照して、本製品または拡張機能に固有のアップグレード情報も確認してください。

発行日: 2024 年 9 月 29 日

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バージョンの見出しの横にあるReport Documentation Bug (ドキュメントバグの報告)リンクを使用できます。リンクを使用すると、Bugzillaで適切な製品とカテゴリが事前に選択され、現在のセクションへのリンクが追加されます。バグレポートの入力を直ちに開始できます。Bugzillaアカウントが必要です。

ドキュメントの編集に貢献

このドキュメントに貢献するには、このドキュメントのHTMLバージョンの見出しの横にあるEdit Source (ソースの編集)リンクを使用してください。GitHubのソースコードに移動し、そこからプル要求を提出できます。GitHubアカウントが必要です。

このドキュメントに使用されるドキュメント環境に関する詳細については、リポジトリのREADMEを参照してください。

メール

ドキュメントに関するエラーの報告やフィードバックは<>宛に送信してください。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してください。関連するセクション番号とタイトル(またはURLを含めて)、問題の簡潔な説明を記載してください。

3 マニュアルの表記規則

このマニュアルでは、次の通知と表記規則が使用されています。

  • /etc/passwd:ディレクトリ名とファイル名

  • PLACEHOLDER:PLACEHOLDERは、実際の値で置き換えられます

  • PATH:環境変数PATH

  • ls--help:コマンド、オプション、およびパラメータ

  • user:ユーザまたはグループ

  • package name: パッケージの名前

  • AltAltF1 :使用するキーまたはキーの組み合わせ、キーはキーボード上と同様、大文字で表示される

  • ファイルファイル › 名前を付けて保存: メニュー項目、ボタン

  • 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へのアップグレードがサポートされます。

サポートされているアップグレードパスの概要
図 1.1: サポートされているアップグレードパスの概要
警告
警告: データベースのアップグレード

この章で説明しているアップグレードパスは、マシンの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によって管理されている場合は、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「メジャーリリースとサービスパック」に、具体的に示します。

メジャーリリースとサービスパック
図 2.1: メジャーリリースとサービスパック

アップグレード計画を設計、検証、およびテストするためにさらに時間が必要な場合、長期サービスパックサポートを利用してサポートを延長することにより、12~36カ月間、追加サポートを受けることができます。これは12カ月単位で延長でき、どのサービスパックに対しても合計2~5年のサポートを利用できます。詳細については、図2.2「長期サービスパックサポート」を参照してください。

長期サービスパックサポート
図 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「セキュリティ更新とバグの修正」を参照してください。

表 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の最新リリースで利用できないものもあることに注意してください。名前が変更されていたり、ほかのパッケージやリリースに置き換えられていたりすることもあります。また、レガシ目的で引き続き提供されていても、デフォルトでは別のパッケージが使用されるパッケージもあります。したがって、ファイルを多少手動で編集しなければならない場合があります。これはテキストエディタで実行できます。

  1. 使用中のすべてのリポジトリのリストを記述したrepositories.bak.repoという名前のファイルを作成します。

    root # zypper lr -e repositories.bak
  2. さらに、すべてのインストール済みパッケージのリストを記述したinstalled-software.bakという名前のファイルも作成します。

    root # rpm -qa --queryformat '%{NAME}\n' >
         installed-software.bak
  3. 両方のファイルをバックアップします。これらのリポジトリとインストール済みパッケージは、次のコマンドで復元できます。

    root # zypper ar repositories.bak.repo
    root # 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に切り替えました。アップグレードを開始する前に、データベースのバックアップを取得することを強くお勧めします。

データベースマイグレーションを実行するには、次の手順を実行します。

  1. ご使用のSUSE Linux Enterprise 11マシンにログインします。

  2. ダンプファイルを作成します。

    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を参照してください。

  3. ダンプファイル、環境設定ファイル、/etc/my.cnf、およびディレクトリ、/etc/mysql/を後で調べることができるように(インストールのためではありません)安全な場所に保存します。

  4. SUSE Linux Enterprise Serverのアップグレードを実行します。アップグレードが終わっても、前の環境設定ファイル、/etc/my.cnfは前のままです。新しい設定は、/etc/my.cnf.rpmnewファイルで確認できます。

  5. 必要に応じて、MariaDBデータベースを設定します。以前の環境設定ファイルとディレクトリを使わないでください。これらは、リマインダとして使用し、活用するだけです。

  6. MariaDBサーバを起動して確認してください。

    root # systemctl start mariadb

    ブートのたびにMariaDBサーバを起動する場合は、そのサービスを有効にします。

    root # systemctl enable mariadb
  7. MariaDBが適切に稼働していることを、データベースに接続して確認します。

    root # mariadb -u root -p

3.5.3 JavaアプリケーションのMD5以外のサーバ証明書の作成

SP1からSP2に更新するときに、MD5ベースの証明書はセキュリティ修正の一環として無効にされました。MD5として作成された証明書を持っている場合、次の手順で証明書を再作成してください。

  1. 端末を開いて、rootとしてログインします。

  2. 秘密鍵を作成します。

    root # openssl genrsa -out server.key 1024

    より強力な鍵が必要な場合、10244096などの大きい数に置き換えます。

  3. 証明書署名要求(CSR)を作成します。

    root # openssl req -new -key server.key -out server.csr
  4. 証明書を自己署名します。

    root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
  5. PEMファイルを作成します。

    root # cat server.key server.crt > server.pem
  6. ファイルserver.crtserver.csrserver.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からのアップグレード

SLE 11からアップグレードする場合、postgresql94がアンインストールされ、PostgreSQLのより高いバージョンにデータベースをマイグレーションするために使用できません。したがって、この場合、システムをアップグレードする「前に」PostgreSQLデータベースをマイグレートしてください。

以下の手順は、バージョン9.6から10へのデータベースマイグレーションについて説明しています。スタートまたはターゲットとして異なるバージョンを使用する場合は、それに応じてバージョン番号を置き換えます。

データベースマイグレーションを実行するには、次の手順を実行します。

  1. 以下の前提条件が満たされていることを確認します。

    • 満たされていない場合、保守アップデートで、古いPostgreSQLバージョンを最新リリースにアップグレードします。

    • 既存のデータベースのバックアップを作成します。

    • 新規のPostgreSQLのメジャーバージョンのパッケージをインストールします。SLES15 SP3の場合、これは postgresql10-server およびそれが依存するすべてのパッケージのインストールを意味します。

    • パッケージ postgresql10-contrib をインストールします。これには、pg_upgradeコマンドが含まれています。

    • ご使用のPostgreSQLデータ領域(デフォルトでは/var/lib/pgsql/data)に十分な空き容量があることを確認します。容量が厳しい場合、次のSQLコマンドをデータベースごとに実行して、サイズを縮小します(長時間要する場合があります)。

      VACUUM FULL
  2. 以下のいずれかでPostgreSQLサーバを停止します。

    root # /usr/sbin/rcpostgresql stop

    あるいは、

    root # systemctl stop postgresql.service

    (アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。

  3. 古いデータディレクトリの名前を変更します。

    root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old
  4. 新規のデータベースインスタンスを初期化します。initdbを使用して手動で実行するか、PostgreSQLを起動、停止することで自動的に実行します。

    root # /usr/sbin/rcpostgresql start
    root # /usr/sbin/rcpostgresql stop

    あるいは、

    root # systemctl start postgresql.service
    root # systemctl stop postgresql.service

    (アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。

  5. 古いバージョンの設定ファイルを変更している場合は、これらの変更を新しい設定ファイルに転送することを検討します。これは、postgresql.auto.confpostgresql.confpg_hba.conf、およびpg_ident.confファイルに影響する場合があります。これらのファイルの古いバージョンは/var/lib/pgsql/data.old/にあり、新しいバージョンは/var/lib/pgsql/dataで見つけることができます。

    古い設定ファイルをコピーすることは推奨されないことに注意してください。コピーすることにより、新しいオプション、新しいデフォルト、および変更されたコメントが上書きされる場合があるためです。

  6. ユーザの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/"
  7. 新しいデータベースインスタンスを次のいずれかを使用して開始します。

    root # /usr/sbin/rcpostgresql start

    あるいは、

    root # systemctl start postgresql.service

    (アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。

  8. マイグレーションが成功したかどうか確認します。テスト範囲はユースケースによって異なり、このステップを自動化する汎用ツールはありません。

  9. すべての古いPostgreSQLパッケージと古いデータディレクトリを削除します。

    root # zypper search -s postgresql96 | xargs zypper rm -u
    root # 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サーバからマシンの登録を解除します。その後、アップグレードプロセスを再開します。

手順 3.1: SMTサーバからSUSE Linux Enterpriseクライアントの登録を解除する
  1. クライアントマシンにログインします。

  2. 次のステップは、クライアントの現在のオペレーティングシステムによって異なります。

    • SUSE Linux Enterprise 11の場合、次のコマンドを実行します。

      tux > sudo suse_register -E
      tux > sudo rm -f /etc/SUSEConnect
      tux > 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.cache
      tux > sudo rm -f /etc/zmd/deviceid
      tux > sudo rm -f /etc/zmd/secret
    • SUSE Linux Enterprise 12の場合、次のコマンドを実行します。

      tux > sudo SUSEConnect --de-register
      tux > sudo SUSEConnect --cleanup
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
  3. SMTサーバにログインします。

  4. すべてのクライアントの登録を一覧にして、クライアントが正常に登録解除されているかどうかを確認します。

    tux > sudo smt-list-registrations
  5. クライアントのホスト名がまだこのコマンドの出力に一覧表示されている場合は、最初の列からクライアントの固有のIDを取得します。(クライアントは複数のIDで一覧表示されている場合があります。)

  6. このクライアントの登録を削除します。

    tux > sudo smt-delete-registration -g UNIQUE_ID
  7. クライアントが複数のIDで一覧表示されている場合は、その固有のIDのそれぞれについてこのステップを繰り返します。

  8. 次のコマンドを再実行して、クライアントが正常に登録解除されているかどうかを確認します。

    tux > sudo smt-list-registrations

3.9 ディスクスペース

ソフトウェアは、バージョンが上がるたびに増加する傾向があります。そのため、更新する前に、使用可能名パーティションの容量を調べてください。ディスク容量が不足する可能性がある場合は、データをバックアップしてから、パーティションのサイズを変更するなどして、使用可能な容量を増やしてください。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。

注記
注記: YaSTでの十分な容量の自動確認

更新手順の実行中に、YaSTは空きディスク容量を確認し、インストールで使用可能な容量を超える可能性がある場合は、ユーザに警告を表示します。その場合、更新を実行すると、「システムが使用できなくなる」ことがあります。操作の内容を(事前のテストによって)確実に把握している場合にのみ、この警告をスキップして更新を続行できます。

3.9.1 Btrfs以外のファイルシステムにおける空きディスク容量の確認

dfコマンドを使用して、使用可能なディスク容量を表示できます。たとえば、例3.1「df -hの出力例」では、ルートパーティションは/dev/hda3です(/としてマウントされています)。

例 3.1: 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 list
    root # 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/displaymanagerDISPLAYMANAGER_STARTS_XSERVERの設定を次のように変更します。

DISPLAYMANAGER_STARTS_XSERVER="yes"

4 オフラインでのアップグレード

この章では、インストールメディアからブートしたYaSTを使用して、既存のSUSE Linux Enterpriseインストール環境をアップグレードする方法を説明します。YaSTインストーラは、たとえばDVDから起動したり、ネットワーク上で起動したり、システムが存在するハードディスクから起動したりできます。

4.1 概念の概要

システムをアップグレードする前に、まず第3章 「アップグレードの準備をお読みください。

システムをアップグレードするには、新規インストールの場合と同じようにインストールソースからブートします。ただし、ブート画面が表示されたときに、アップグレードを選択します(インストールではありません)。アップグレードは次の場所から開始できます。

4.2 インストールメディアからのアップグレードの開始

次の手順では、DVDからブートする方法を説明していますが、USB大容量ストレージデバイス上のISOイメージなど、他のローカルインストールメディアを使用することもできます。どのメディアとブート方法を選択するかは、システムアーキテクチャと、マシンに従来のBIOSまたはUEFIのどちらが搭載されているかによって決まります。

手順 4.1: SUSE Linux Enterprise Server 15 SP3への手動アップグレード
  1. ブートメディアを選択して準備します。Book “導入ガイドを参照してください。

  2. SUSE Linux Enterprise Server 15 SP3用の統合インストーラDVDを挿入し、マシンを起動します。ようこそ画面が表示され、続けてブート画面が表示されます。

  3. オプション: インストーラにネットワークソースからではなく、DVDからのみパッケージをインストールすることを強制するには、ブートオプションmedia_upgrade=1を追加します。

  4. ブートメニューで[アップグレード]を選択してシステムを起動します。

  5. 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が装備されているかどうかによって異なります。詳しくは、以下のリンクを参照してください。

  1. SUSE Linux Enterprise Server 15 SP3用の統合インストーラDVDを挿入し、マシンを起動します。ようこそ画面が表示され、続けてブート画面が表示されます。

  2. 使用するネットワークインストールソースのタイプ(FTP、HTTP、NFS、SMB、またはSLP)を選択します。通常、選択肢はF4キーを押すと表示されますが、ご使用のマシンに従来型のBIOSではなくUEFIが搭載されている場合は、パラメータを手動で調整しなければならない場合があります。詳細については、Book “導入ガイド”, Chapter 7 “ブートパラメータ”およびBook “導入ガイド”, Chapter 8 “インストール手順”を参照してください。

  3. 4.4項 「SUSE Linux Enterpriseのアップグレード」の説明に従って、アップグレードプロセスを進めます。

4.3.2 ネットワークインストールソース経由での手動アップグレード - PXEでのブート

PXEブートを使用して、ネットワークインストールソースからアップグレードを実行するには、以下のようにします。

  1. DHCPサーバの設定を調整してPXEブートに必要なアドレス情報を指定します。詳細については、Book “導入ガイド”, Chapter 17 “ネットワークブート環境の準備”, Section 17.1.1 “動的アドレス割り当て”を参照してください。

  2. PXEブートに必要なブートイメージを保管するTFTPサーバを設定します。これにはSUSE Linux Enterprise Server 15 SP3用のインストーラDVDを使用するか、Book “導入ガイド”, Chapter 17 “ネットワークブート環境の準備”, Section 17.2 “TFTPサーバのセットアップ”の説明に従ってください。

  3. ターゲットマシンにPXEブートとWake-on-LANを準備します。

  4. ターゲットシステムのブートを開始し、VNCを使用してこのコンピュータで実行中のインストールルーチンにリモートで接続します。詳細については、Book “導入ガイド”, Chapter 11 “リモートインストール”, Section 11.3 “VNCによるインストールの監視”を参照してください。

  5. 4.4項 「SUSE Linux Enterpriseのアップグレード」の説明に従って、アップグレードプロセスを進めます。

4.4 SUSE Linux Enterpriseのアップグレード

システムのアップグレード前に、第3章 「アップグレードの準備をご覧ください。自動マイグレーションを実行するには、次の手順に従います。

注記
注記: SUSEカスタマーセンターとインターネット接続

アップグレードするシステムがSUSEカスタマーセンターに登録されている場合は、次の手順の間にインターネットに接続されていることを確認してください。

  1. ブートした後(インストールメディアまたはネットワーク、いずれかの方法による)、ブート画面のアップグレードエントリを選択します。

    警告
    警告: 選択を間違えるとデータを失う場合があります。

    この時点でアップグレードを選択していることを確認してください。間違ってインストールを選択すると、データパーティションが新しいインストールで上書きされます。

    YaSTはインストールシステムを起動します。

  2. ようこそ画面で、言語およびキーボードを選択します。次へで続行します。

    YaSTは、インストール済みのSUSE Linux Enterpriseシステムのパーティションをチェックします。

  3. Select for Upgrade(アップグレードの選択)画面で、アップグレードするパーティションを選択して、次へをクリックします。

  4. YaSTは、選択したパーティションをマウントし、アップグレードした製品の使用許諾契約を表示します。続行するには、使用許諾契約を受諾します。

  5. 以前に利用していたリポジトリ画面で、リポジトリのステータスを調整します。デフォルトでは、すべてのリポジトリが削除されます。カスタムリポジトリを追加していない場合は、設定を変更しないでください。アップグレード用のパッケージは、DVDからインストールされ、次の手順では、オプションでデフォルトのオンラインリポジトリを有効にすることができます。

    カスタムリポジトリがある場合は、次の2つの選択肢があります。

    • リポジトリを削除済み状態のままにする。このリポジトリからインストールされたソフトウェアはアップグレード中に削除されます。新しいリリースに一致するリポジトリのバージョンが使用できない場合はこの方法を使用します。

    • リポジトリが新しいリリースに一致する場合はアップデートして有効にする。リストでリポジトリをクリックしてそのURLを変更し、変更をクリックします。状態の変更有効に設定されるまでチェックして、リポジトリを有効にします。

    システムが不安定であるか、まったく機能しない場合があるため、以前のリリースのリポジトリを保持しないでください。次へをクリックして続行します。

  6. 次の手順は、アップグレードしたシステムがSUSEカスタマーセンターに登録されているかどうかにより異なります。

    1. システムがSUSEカスタマーセンターに登録されていない場合、YaSTには2つめのインストールメディアである、SLE-15-SP2-Full-ARCH-GM-media1.isoイメージを使用することを提案するポップアップメッセージが表示されます。

      このメディアがない場合、登録せずにシステムをアップグレードすることはできません。

    2. システムがSUSEカスタマーセンターに登録されている場合、可能性のあるマイグレーションターゲットとサマリが表示されます。

      リストからマイグレーションターゲットを1つ選択し、次へで続行します。

  7. 次のダイアログで、追加のインストールメディアをオプションで追加できます。追加のインストールメディアがある場合は、追加のアドオン製品をインストールするオプションを有効にして、メディアタイプを指定します。

  8. アップグレードのインストール設定を確認します。

  9. すべての設定を希望どおりに完了したら、アップデートをクリックして、インストールおよび削除の手順を開始します。

    ヒント
    ヒント: SMTクライアントでのアップグレードの失敗

    アップグレードするマシンがSMTクライアントで、アップグレードが失敗する場合は、手順3.1「SMTサーバからSUSE Linux Enterpriseクライアントの登録を解除する」を参照して、後でアップグレード手順を再開してください。

  10. アップグレードプロセスが正常に終了した後で、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カスタマーセンターへのアクセス

  1. YaSTを起動し、ソフトウェア › 製品登録を選択して、登録ダイアログを開きます。

  2. 各自または各自の組織が登録の管理に使用しているSUSEアカウントに関連付けられた電子メールアドレスを指定します。SUSEアカウントをまだ作成していない場合は、SUSEのカスタマセンターのホームページ(https://scc.suse.com/)でアカウントを作成します。

  3. SUSE Linux Enterprise Serverに添付されている登録コードを入力します。

  4. ネットワーク上で1台または複数台のローカル登録サーバが使用可能な場合は、リストに示されたサーバのうちいずれかを選択できます。

  5. 登録を開始するには、次へで続行します。

    正常に登録されると、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クライアントのアップグレード

アップグレードするシステムがSUSE Managerクライアントの場合は、YaSTオンラインマイグレーションやzypper migrationではアップグレードできません。代わりに、「Client Migration」手順を使用してください。『 SUSE Manager Upgrade Guide』で説明されています。

5.2 サービスパックのマイグレーションのワークフロー

サービスパックのマイグレーションは、YaST、zypper、またはAutoYaSTにより実行できます。

サービスパックのマイグレーションを開始する前に、SUSEカスタマーセンターまたはローカルRMTサーバでシステムを登録する必要があります。SUSE Managerも使用できます。

どの方法を使用する場合も、サービスパックのマイグレーションは次の手順で構成されます。

  1. 登録システムで、マイグレーションターゲットの候補を見つけます。

  2. マイグレーションターゲットを1つ選択します。

  3. 新しいリポジトリを要求して有効にします。

  4. マイグレーションを実行します。

マイグレーションターゲットのリストは、インストールおよび登録されている製品に応じて異なります。新しいSPがまだ利用可能になっていない拡張機能がインストールされている場合、マイグレーションターゲットが提供されない可能性があります。

ホストで使用可能なマイグレーションターゲットのリストは、常にSUSEカスタマーセンターから取得され、インストールされている製品または拡張機能に応じて異なります。

5.3 サービスパックのマイグレーションのキャンセル

サービスパックのマイグレーションは、マイグレーションプロセスの特定の段階でのみキャンセルできます。

  1. パッケージのアップグレードが開始されるまで、システムには、サービスやリポジトリなどの最小限の変更しか加えられません。以前の状態に戻すには、/etc/zypp/repos.d/*を復元します。

  2. パッケージのアップグレードが開始された後は、Snapperスナップショットを使用して以前の状態に戻すことができます(Book “管理ガイド”, Chapter 7 “Snapperを使用したシステムの回復とスナップショット管理”を参照してください)。

  3. マイグレーションターゲットが選択された後、SUSEカスタマーセンターによってリポジトリデータが変更されます。この状態を手動で元に戻すには、SUSEConnect --rollbackを使用します。

5.4 オンラインマイグレーションツール(YaST)を使用したアップグレード

YaSTを使用してサービスパックのマイグレーションを実行するには、Online Migration (オンラインマイグレーション)ツールを使用します。デフォルトでは、YaSTはサードパーティリポジトリからパッケージをインストールしません。パッケージがサードパーティリポジトリからインストールされている場合、YaSTは、SUSEから提供されている同じパッケージによってパッケージが置き換えられるのを防ぎます。

注記
注記: インストールサイズの削減

サービスパックのマイグレーションの実行時に、YaSTは推奨パッケージをすべてインストールします。特にカスタム最小インストールの場合、これによってシステムのインストールサイズが大幅に増加することがあります。

このデフォルトの動作を変更し、必要なパッケージのみを許可するには、/etc/zypp/zypp.confで、solver.onlyRequiresオプションを調整します。

solver.onlyRequires = true

また、ファイル/etc/zypp/zypper.confを編集して、installRecommendsオプションを変更します。

installRecommends=false

これにより、パッチや新しいパッケージのインストールなど、すべてのパッケージ操作の動作が変更されます。1回の起動に対してのみZypperの動作を変更するには、パラメータ--no-recommendsをコマンドラインに追加します。

サービスパックのマイグレーションを開始するには、次の手順を実行します。

  1. 登録サーバ上の未使用の拡張機能をすべて無効にして、将来、依存関係の競合が発生が発生するのを防ぎます。拡張機能を覚えていなくても、後でYaSTによって未使用の拡張機能リポジトリが検出され、無効にされます。

  2. 更新するマシンで実行されているGNOMEセッションにログインしている場合は、テキストコンソールに切り替えます。GNOMEセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、GNOMEでVNCセッションを実行している場合を除きます)。

  3. YaSTオンラインアップデートを実行して、システム用の最新のパッケージのアップデートを取得します。

  4. パッケージ yast2-migration およびその依存関係をインストールします(YaSTの ソフトウェア ›  ソフトウェア管理 )。

  5. YaSTを再起動します。再起動しないと、新しくインストールしたモジュールがコントロールセンターに表示されません。

  6. YaSTで、Online Migration (オンラインマイグレーション)を選択します(アップグレードするSUSE Linux Enterprise Serverのバージョンによって、このモジュールはシステムまたはソフトウェアの下にあります)。可能性のあるマイグレーションターゲットと概要がYaSTによって表示されます。システムで使用可能なマイグレーションターゲットが複数ある場合は、リストから1つを選択します。

  7. リストからマイグレーションターゲットを1つ選択し、次へで続行します。

  8. マイグレーションツールによってアップデートリポジトリが提供される場合は、はいで続行することをお勧めします。

  9. [Online Migration (オンラインマイグレーション)]ツールにより、DVDまたはローカルサーバから提供されている古いリポジトリが検出される場合は、それらを無効にすることを強くお勧めします。古いリポジトリは以前のSPのものです。SUSEカスタマーセンターまたはRMTからの古いリポジトリは、すべて自動的に削除されます。

  10. 概要を確認し、次へをクリックしてマイグレーションを続行します。更新開始を選択して確認します。

  11. マイグレーションが正常に完了したら、システムを再起動します。

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をコマンドラインに追加します。

サービスパックのマイグレーションを開始するには、次の手順を実行します。

  1. 更新するマシンで実行されているGNOMEセッションにログインしている場合は、テキストコンソールに切り替えます。GNOMEセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、GNOMEでVNCセッションを実行している場合を除きます)。

  2. SUSE Linux Enterpriseマシンをまだ登録していない場合は登録します。

    tux > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. マイグレーションを開始します。

    tux > sudo zypper migration

    マイグレーションプロセスに関する注記

    • システムで使用可能なマイグレーションターゲットが複数ある場合は、Zypperでリストから1つを選択できます。これはSPを1つまたは複数スキップするのと同じことです。基本製品(SLES、SLED)のオンラインマイグレーションを使用できるのは、メジャーバージョンのSP間のみであることに注意してください。

    • デフォルトでは、Zypperは、zypper dupに渡されるオプション--no-allow-vendor-changeを使用します。パッケージがサードパーティリポジトリからインストールされている場合、このオプションにより、SUSEから提供されている同じパッケージによって該当するパッケージが置き換えられるのを防ぎます。

    • Zypperにより、DVDまたはローカルサーバから提供されている古いリポジトリが検出される場合は、それらを無効にすることを強くお勧めします。SUSEカスタマーセンターまたはRMTからの古いリポジトリは自動的に削除されます。

  4. すべての変更内容を確認します。特に、削除されるパッケージに注意してください。「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):

    シェルをスクロールするには、ShiftPage ↑ またはShiftPage ↓ キーを使用します。

  5. マイグレーションが正常に完了したら、システムを再起動します。

5.6 プレーンZypperによるアップグレード

インターネットや登録サーバにアクセスできないため、システムが登録されていない場合、YaSTマイグレーションまたはzypper migrationを使用して新しいサービスパックに移行することはできません。この場合でも、プレーンZypperやいくつかの手動での対話操作により新しいサービスパックに移行することができます。

重要
重要: 未登録システムの場合のみ

新しいサービスパックへのこのマイグレーションパスは、インターネットや登録サーバにアクセスできない未登録システムに「のみ」サポートされています。たとえば、特別に保護されたネットワーク内のマシンの場合などです。システムが登録済みである場合は、YaSTまたはZypperマイグレーションを使用してください。

重要
重要: インストールソース

このマイグレーションパスでは、移行するマシンによってアクセス可能な場所に新しいサービスパックのインストールソースを提供する必要があります。これは、たとえば、RMTサーバやSLPサーバをセットアップすることによって実現できます。

システムがインストール済みの製品バージョンの最新のアップデートリポジトリにアクセスできる必要もあります。

  1. 移行するマシンで実行されているグラフィカルセッションにログインしている場合は、そのセッションをログアウトして、テキストコンソールに切り替えます。グラフィカルセッション内からアップデートを実行することはお勧めしません。これは、リモートマシンからログインしている場合には該当しません(ただし、XでVNCセッションを実行している場合を除きます)。

  2. SUSE Linux Enterpriseの古いリポジトリを使用してパッケージ管理ツールを更新します。

    tux > sudo zypper patch --updatestack-only
  3. 現在リポジトリが割り当てられていないパッケージ(孤立したパッケージ)のリストを取得します。これらのパッケージは移行されず、マイグレーション後に動作する保証はありません(依存する他のパッケージは互換性がなくなったため変更されている可能性があるため)。リストを取得するには、次のコマンドを実行します:

    tux > sudo zypper packages --orphaned

    リストを注意深く確認して、必要なくなったすべての孤立パッケージを削除します。残りのすべての孤立パッケージをメモしてください。後で比較用に必要となります。

  4. 次のコマンドを実行して、システムが現在サブスクライブしているすべてのリポジトリのリストを取得します。

    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を変更するには、次のオプションがあります。

    1. YaST › ソフトウェア › ソフトウェアリポジトリの使用。リポジトリを選択して、編集をクリックして必要な変更を行います。すべてのリポジトリに対してこれを繰り返します。

    2. Zypperの使用。次のコマンドを実行して、古いリポジトリを削除します。

      tux > sudo zypper removerepo OLD_REPO_ID

      削除後、対応する新しいリポジトリを次のコマンドを実行して追加します。

       tux > sudo zypper addrepo -f URL NAME-15-SP3
    3. /etc/zypp/repos.dでリポジトリ設定ファイルを編集する。各リポジトリは1つの設定ファイルで表されます。各ファイルで、baseurlパラメータの値を変更する必要があります。

  5. zypper repos -uを実行して変更を確認し、次のコマンドを実行してリポジトリをアップデートします。

    tux > sudo zypper refresh -f -s

    リポジトリのアップデートに失敗した場合は、間違ったURLを入力していないか再確認します。問題が修正できない場合は、失敗したリポジトリを無効にすることをお勧めします。

    すべてのリポジトリが正常に設定された場合は、次のコマンドを再度実行して、

    tux > sudo zypper refresh -f -s

    「すべて」のリポジトリが最新であることを確認します。

  6. マイグレーションを開始する前に、まずテストランを実行することをお勧めします。

    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オプションは、初期インストール時に選択解除したパッケージが再び追加されないようにします。

  7. マイグレーションが終了して、システムが新しいサービスパックバージョンで起動したら、孤立パッケージのチェックを再度実行します。

    tux > sudo zypper packages --orphaned

    新しいリストとマイグレーションを開始する前に生成されたリストを比較します。リストに新しいパッケージが表示された場合は、新しいサービスパックの別のモジュールに移動されたことが原因である可能性があります。以前のインストールにそのモジュールがなかった場合、このパッケージはアップデートされていません。

    https://scc.suse.com/packagesでパッケージが属するモジュールを確認できます。zypper addrepoまたはYaSTソフトウェアリポジトリモジュールを使用して、不足しているモジュールを追加し、次のコマンドを実行して後で孤立パッケージをアップデートします。

    tux > sudo zypper install --no-recommends LIST OF PACKAGES
  8. 新しいサービスパックに正常に移行しました。

5.7 サービスパックのロールバック

サービスパックの有効性が認められない場合は、SUSE Linux Enterpriseシステムをサービスパックのマイグレーションが開始される前の状態に戻すことができます。このためには、スナップショットが有効なBtrfsルートパーティションであることが前提条件です(これはSLES 12以降のデフォルトです)。詳細についてはBook “管理ガイド”, Chapter 7 “Snapperを使用したシステムの回復とスナップショット管理”を参照してください。

  1. すべてのSnapperスナップショットのリストを取得します。

    tux > sudo snapper list

    出力を確認して、サービスパックのマイグレーションの開始直前に作成されたスナップショットを見つけます。列Descriptionには対応するステートメントが含まれており、スナップショットには列Userdataimportantというマークが付いています。列#のスナップショット番号と、列Dateの日付を覚えます。

  2. システムを再起動します。ブートメニューからStart boot loader from a read-only snapshot (読み込み専用スナップショットからブートローダを起動)を選択して、前の手順で覚えた日付と番号が付いたスナップショットを選択します。2番目のブートメニュー(スナップショットのブートメニュー)がロードされます。SLES 15 SP3で始まるエントリを選択して起動します。

  3. システムが以前の状態で起動し、システムパーティションは読み込み専用でマウントされます。rootとしてログインし、正しいスナップショットを選択しているかどうかを確認します。また、すべてが正常に機能することも確認します。ルートファイルシステムは読み込み専用でマウントされるため、機能の制限が適用される場合があることに注意してください。

    問題がある場合、または間違ったスナップショットをブートした場合は、再起動して、ブート元として別のスナップショットを選択します。この時点では、恒久的な変更は加えられていません。スナップショットが正しく、正常に機能する場合、次のコマンドを実行して変更を確定します。

    tux > sudo snapper rollback

    続いて再起動を行います。ブート画面で、デフォルトのブートエントリを選択して、復元されたシステムで再起動します。

  4. リポジトリの設定が適切にリセットされているかどうかを確認します。さらに、すべての製品が適切に登録されているかどうかも確認します。いずれかが間違っていると、後でシステムを更新しようとしてもできなかったり、間違ったパッケージリポジトリを使用してシステムが更新されたりすることがあります。

    次の手順を開始する前に、システムがインターネットにアクセスできることを確認してください。

    1. 次のコマンドを実行して、サービスとリポジトリを更新します。

      tux > sudo zypper ref -fs
    2. 次のコマンドを実行して、アクティブなリポジトリのリストを取得します。

      tux > sudo zypper lr

      このコマンドの出力を入念に確認します。更新対象として追加したサービスとリポジトリが一覧にされていてはなりません。たとえば、SLES 15 SP3からSLES15 GAへのマイグレーションをロールバックする場合、SLES15-SP3のリポジトリではなく、SLES15-GAのリポジトリがリストに含まれている必要があります。

      間違ったリポジトリが一覧にされている場合は削除し、必要に応じて、製品またはサービスパックのバージョンに一致するバージョンに置き換えます。サポートされるマイグレーションパスのリポジトリのリストについては、2.3項 「モジュールの依存関係とライフサイクル」を参照してください。(リポジトリは自動的に更新されるため、手動での操作は必要ありませんが、確認して必要な修正を行うことがベストプラクティスです。)

    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パッケージをマイグレートできない

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”を参照してください。

手順 5.1: openSUSE LeapからSUSE Linux Enterprise Serverへのアップグレード

openSUSE LeapからSUSE Linux Enterprise Serverにマイグレートするには、以下の手順に従ってください。

  1. たとえば、CtrlAltF1を押して、TTYに切り替えます。rootとしてログインします。

  2. yast2- registration および rollback-helper パッケージをインストールします。

    root # zypper in yast2-registration rollback-helper
  3. rollback-helperサービスを有効化します。

    root # systemctl enable rollback
  4. SUSEカスタマーセンターにシステムを登録します。

    root # yast2 registration
  5. マイグレーションを実行します。

    root # yast2 migration

    パッケージが競合する場合は、YaSTが対処法のリストを表示するので、そこから選択します。

  6. 孤立したパッケージを削除します。

    root # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  7. システムを再起動します。

    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-package
    tux > 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)プロジェクトによって管理されています。