目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / 導入ガイド / SUSE Linux Enterpriseの更新とアップグレード / SUSE Linux Enterpriseのアップグレード
適用項目 SUSE Linux Enterprise Server 12 SP5

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

SUSE® Linux Enterprise (SLE)では、既存のシステムを新しいバージョンにアップグレードできます。新たにインストールする必要はありません。ホームディレクトリ、データディレクトリ、システム設定などの既存のデータは、そのまま保持されます。CD/DVDドライブから、またはネットワーク上にある中央のインストールソースからアップデートできます。

この章では、DVD、ネットワーク、自動化プロセス、SUSE Managerなどを使用して、SUSE Linux Enterprise システムを手動でアップグレードする方法について説明します。

19.1 SLE SP5へのサポートされているアップグレードパス

サポートされているアップグレードパスの概要
図 19.1: サポートされているアップグレードパスの概要
重要
重要: クロスアーキテクチャアップグレードはサポートされない

クロスアーキテクチャアップグレードは「サポートされません」。たとえば、32ビットバージョンのSUSE Linux Enterprise Serverから64ビットバージョンへのアップグレードや、ビッグエンディアンからリトルエンディアンへのアップグレードなどがこれに該当します。

具体的には、POWER版のSLE 11(ビッグエンディアン)からPOWER版のSLE 12 SP2(新規: リトルエンディアン)はサポートされません

同様に、SUSE Linux Enterprise 12は、64ビット専用であるため、32ビットのSUSE Linux Enterprise 11システムからSUSE Linux Enterprise 12以降へのアップグレードもサポートされません

クロスアーキテクチャアップグレードを行いたい場合は、新規インストールを実行する必要があります。

注記
注記: サービスパックのスキップ

最も安全なアップグレードパスは、順を追って進み、すべてのサービスパックを連続的にインストールすることです。場合によっては、アップグレード時に1~2個のサービスパックをスキップできます。詳細については、バージョンごとにサポートされているアップグレードパスおよび図19.1「サポートされているアップグレードパスの概要」を参照してください。ただし、どのサービスパックも「スキップしない」ことをお勧めします。

注記
注記: メジャーリリースへのアップグレード

新しいメジャーリリースにアップグレードする際には、新たにインストールすることをお勧めします。

バージョンごとにサポートされているアップグレードパス
SUSE Linux Enterprise 10 (任意のサービスパック)からのアップグレード

SUSE Linux Enterprise 12への直接的なマイグレーションパスはサポートされていません。この場合、新規インストールをお勧めします。

SUSE Linux Enterprise 11 GA/SP1/SP2/SP3からのアップグレード

SUSE Linux Enterprise 12への直接的なマイグレーションパスはサポートされていません。12 SP5に進むには、まずSLE 11 SP4が必要です。

新規インストールを行うことができない場合は、まず、インストールされているSLE 11のサービスパックをSLE 11 SP4にアップグレードします。これらのステップについては、SUSE Linux Enterprise 11の「導入ガイド」で説明しています(https://documentation.suse.com/sles-11/)。

SUSE Linux Enterprise 11 SP4からのアップグレード

SLE 11 SP5からSLE 12 SP4へのアップグレードは、オフラインアップグレードでのみサポートされます。詳細については、第20章 「オフラインでのアップグレードを参照してください。

SUSE Linux Enterprise 12 GA/SP1/SP2/SP3からSP5へのアップグレード

SLE 12 GA、SP1、SP2、またはSP3からSP5への直接アップグレードはサポートされていません。 最初にSLE12SP4へアップグレードしてください。

SUSE Linux Enterprise 12 SP4からSP5へのアップグレード

SUSE Linux Enterprise 12 SP4からSP5へのアップグレードはサポートされます。

SUSE Linux Enterprise 12 LTSS GA/SP1/SP2からSP5へのアップグレード

SUSE Linux Enterprise 12 LTSS GA、SP1、またはSP2からSP5への直接アップグレードはサポートされていません。最初にSLE12 LTSS SP3またはSP4へアップグレードしてください。

SUSE Linux Enterprise 12 LTSS SP3/SP4からSP5へのアップグレード

SUSE Linux Enterprise 12 LTSS SP3またはSP4からSP5へのアップグレードがサポートされています。

19.2 オンラインおよびオフラインでのアップグレード

SUSEは、アップグレードおよびマイグレーションの方法として2つの異なる方法サポートしています。用語の詳細については、18.1項 「用語集」を参照してください。次の2つの方法があります。

オンライン

稼働中のシステムから実行するすべてのアップグレードをオンラインとみなします。たとえば、SUSEカスタマーセンター経由で接続したアップグレード、Subscription Management Tool (SMT)でのアップグレード、ZypperまたはYaSTを使用したSUSE Managerでのアップグレードなどです。

同じメジャーリリースのサービスパック間でマイグレートする場合は、21.4項 「オンラインマイグレーションツール(YaST)を使用したアップグレード」または21.5項 「Zypperによるアップグレード」に従うことをお勧めします。

オフライン

オフラインでの方法では、通常、別のオペレーティングシステムをブートし、そこからインストールされているSLEバージョンをアップグレードします。たとえば、DVD、フラッシュディスク、ISOイメージ、AutoYaST、プレーンRPM、PXEブートなどを使用したアップグレードです。

重要
重要: SUSE Managerクライアント

ご使用のマシンがSUSE Managerで管理されている場合、アップグレード手順は管理インタフェースで開始する必要があります。詳細については、20.6項 「SUSE Managerによるアップデート」を参照してください。

19.3 システムの準備

アップグレード手順を開始する前に、システムが正しく準備されていることを確認します。準備内容には、データのバックアップとリリースノートの確認などがあります。

19.3.1 現在のシステムが最新であることを確認する

システムのアップグレードは、最新のパッチレベルからのみサポートされます。zypper patchを実行するか、YaSTモジュールオンライン更新を実行して、最新のシステムの更新がインストールされていることを確認します。

19.3.2 リリースノートの確認

リリースノートには、旧リリースのSUSE Linux Enterprise Serverからの変更点に関する追加情報が記載されています。リリースノートを参照して以下を確認します。

  • 使用しているハードウェアに特別な配慮が必要かどうか

  • 使用しているソフトウェアパッケージに大幅な変更があるかどうか

  • インストールのために特別な予防措置が必要かどうか

リリースノートには、マニュアルに記載できなかった情報が記載されています。また、既知の問題に関する注意も記載されています。

サービスパックを1つ以上スキップする場合は、スキップするサービスパックのリリースノートも確認します。通常、リリースノートにはそれに続く2つのリリースの変更しか記載されていません。最新のリリースノートしか読まないと、重要な変更を見落とす可能性があります。

リリースノートは、ローカルではディレクトリ/usr/share/doc/release-notesに、オンラインではhttps://www.suse.com/releasenotes/にあります。

19.3.3 バックアップの作成

更新の前に、既存の設定ファイルを別個のメディア(テープデバイス、リムーバブルハードディスクなど)にコピーして、データをバックアップします。主に、/etcに保存されているファイル、および/var/optのディレクトリとファイルの一部に当てはまります。さらに、/home (HOMEディレクトリ)下のユーザデータをバックアップメディアに書き込むようにします。このデータは、rootユーザでバックアップします。rootのみに、すべてのローカルファイルに関する読み込みパーミッションがあります。

YaSTのインストールモードとして既存システムの更新を選択している場合は、もっと後の時点で(システム)バックアップを実行することができます。変更されたすべてのファイルと/etc/sysconfigディレクトリにあるファイルを含めることができます。ただし、これは完全なバックアップではありません。前述したその他の重要なディレクトリがすべて含まれていないからです。/var/adm/backupディレクトリでバックアップを見つけます。

19.3.3.1 インストール済みパッケージとリポジトリの一覧

インストール済みパッケージのリストを用意しておくと、いろいろな場面で役立ちます。たとえば、新しいメジャーSLEリリースを新規インストールする場合や、旧バージョンに戻す場合などです。

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

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

root # zypper lr -e repositories.bak

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

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

両方のファイルをバックアップします。これらのリポジトリとインストール済みパッケージは、次のコマンドで復元できます。

root # zypper ar repositories.bak
root # zypper install $(cat installed-software.bak)
注記
注記: 新しいメジャーリリースへの更新によりパッケージの量が増える

新しいメジャーバージョン(SLE X+1)にアップグレードされるシステムには、最初のシステム(SLE X)より多くのパッケージが含まれる場合があります。同じパターンを選択したSLE X+1の新規インストールよりも多くのパッケージが含まれる場合もあります。その理由は次のとおりです。

  • パッケージをより細かく選択できるように、パッケージが分割されています。たとえば、SLE 11の37個の texlive パッケージは、SLE 12では422個のパッケージに分割されました。

  • パッケージが個々のパッケージに分割された際、以前のバージョンと同じ機能を保つために、新しいパッケージはすべて、アップグレードとしてインストールされるようになりました。ただし、SLE X+1の新規インストールの新しいデフォルトでは、すべてのパッケージをインストールしない場合があります。

  • SLE Xからの古いパッケージが、互換性の理由で保持されている可能性があります。

  • パッケージの依存関係およびパターンの範囲が変更されている可能性があります。

19.3.4 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. アップグレードを実施します。アップグレードが終わっても、前の環境設定ファイル、/etc/my.cnfは前のままです。新しい設定は、/etc/my.cnf.rpmnewファイルで確認できます。

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

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

    root # systemctl start mysql

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

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

    root # mysql -u root -p

19.3.5 PostgreSQLデータベースの移行

新しいバージョンのPostgreSQLデータベースは保守アップデートとして出荷されます。データベースのマイグレーション作業が必要であることから、自動アップグレードプロセスはありません。そのため、あるバージョンから別のバージョンへの切り替えは、手動で行わなければなりません。

マイグレーションプロセスは、pg_upgradeコマンドで行います。このコマンドは、従来のdumpとreloadコマンドに代わる方式です。dump とreload方式と比べると、pg_upgradeの場合、マイグレーションの時間が短縮されます。

各PostgreSQLバージョンのプログラムファイルは、異なる、バージョン依存のディレクトリに格納されます。たとえば、バージョン9.6の場合は/usr/lib/postgresql96/、バージョン10の場合は/usr/lib/postgresql10/です。PostgreSQLのバージョニングポリシーが、メジャーバージョン9.6と10の間で変更されていることに注意してください。詳細については、https://www.postgresql.org/support/versioning/を参照してください。

重要
重要: SLE 11からのアップグレード

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

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

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

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

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

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

    • 新規のPostgreSQLのメジャーバージョンのパッケージをインストールします。SLES12 SP5の場合、これは 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

19.3.6 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/です。

19.3.7 仮想マシンゲストのシャットダウン

お使いのマシンがKVMまたはXenのVMホストサーバとして機能している場合、アップデートの前には、実行中のすべてのVMゲストを正しくシャットダウンするようにします。そうでないと、更新後にゲストにアクセスできなくなる可能性があります。

19.3.8 SMTクライアントセットアップの調整

アップグレードするマシンがSMTサーバに対してクライアントとして登録されている場合は、次のことに注意してください。

ホストのclientSetup4SMT.shスクリプトのバージョンが最新であるかどうかを確認します。古いバージョンのSMTのclientSetup4SMT.shはSMT 12クライアントを管理できません。SMTサーバにソフトウェアパッチを定期的に適用している場合、常に最新バージョンのclientSetup4SMT.sh<SMT_HOSTNAME>/repo/tools/clientSetup4SMT.shで見つけることができます。

新しいバージョンのSUSE Linux Enterprise Serverへのマシンのアップグレードが失敗する場合は、手順 19.1の説明に従って、SMTサーバからマシンの登録を解除します。その後、アップグレードプロセスを再開します。

手順 19.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

19.3.9 ディスク容量

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

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

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

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

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

例 19.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

19.3.9.2 Btrfsファイルシステムの空きディスク容量の確認

マシンでBtrfsをルートファイルシステムとして使用している場合、十分な空き容量があることを確認します。多くの場合、アップグレードには、新しいスナップショット用に、現在のルートファイルシステムと同じディスク容量が必要になります(/.snapshotがない場合)。使用可能なディスク容量を表示するには、次のコマンドを使用します。

root # df -h /

ほかのすべてのマウント済みパーティションでも、使用可能な容量を確認します。効果が実証されている推奨事項は次のとおりです。

  • Btrfsを含めてすべてのファイルシステムで、大きなRPMをダウンロードし、インストールできるだけの空きディスク容量が必要です。古いRPMが使用している容量は、新しいRPMのインストール後にのみ解放されます。

  • スナップショットがあるBtrfsの場合、現在のインストールで使用している容量と同じだけの空き容量が最低でも必要です。現在のインストール環境の2倍の空き容量を確保することを推奨します。

    十分な空き容量がない場合、snapperを使用して古いスナップショットを削除することができます。

    root # snapper list
    root # snapper delete NUMBER

    しかし、すべてのケースでこの方法が役立つとは限りません。マイグレーションの前には、大半のスナップショットが占めている容量はごくわずかです。

19.3.10 カーネルのマルチバージョンサポートの一時的な無効化

SUSE Linux Enterprise Serverでは、/etc/zypp/zypp.confの各設定を有効にすることで、複数のカーネルバージョンをインストールできます。特定のサービスパックにアップグレードする場合、この機能のサポートを一時的に無効化する必要があります。更新が正常に完了したら、マルチバージョンサポートを再び有効にできます。マルチバージョンサポートを無効にするには、/etc/zypp/zypp.confの各行をコメント化します。結果は次のようになります。

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

更新が正常に完了した後にこの機能を再アクティブ化するには、コメント記号を削除します。マルチバージョンサポートの詳細については、15.1項 「マルチバージョンサポートの有効化と設定」を参照してください。

19.4 IBM Zでのアップグレード

IBM ZにインストールされたSUSE Linux Enterpriseをアップグレードするには、parmfileなどでカーネルパラメータUpgrade=1を使用する必要があります。詳細については、4.3項 「parmfile: システム設定の自動化」を参照してください。

19.5 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"