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

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 使用可能なディスク容量の確認

 

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

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

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

3.4.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.4.2 Btrfsファイルシステムの空きディスク容量の確認

 

Btrfsファイルシステムでは、dfの出力は誤解を招く可能性があります。生データが割り当てる領域とは別に、Btrfsファイルシステムもメタデータ用の領域を割り当てて使用するからです。

その結果、まだ大量の領域を使用できるように見えても、Btrfsファイルシステムによって領域不足がレポートされることがあります。その場合、メタデータ用に割り当てられた領域はすべて使用されています。Btrfsファイルシステムで使用済みスペースと使用可能スペースを確認する方法の詳細については、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を使用して古いスナップショットを削除することができます。 

    # snapper list
      # snapper delete NUMBER

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

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

 

インストール済みパッケージのリストを記録できます。たとえば、新しいメジャーSLEリリースを新規インストールする場合や、旧バージョンに戻す場合などです。

注記
注記

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

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

    # zypper lr -e repositories.bak

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

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

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

    # zypper ar repositories.bak.repo
# 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.6 LTSS拡張機能を無効にする

 

長期サービスパックサポート(LTSS)を備えたSUSE Linux Enterprise Serverシステムを、まだ一般的なサポート下にあるバージョンにアップグレードすると、No migration available (利用可能なマイグレーションはありません)というエラーでアップグレードが失敗します。このエラーは、zypper migrationが「すべての」リポジトリをマイグレートしようとするが、まだ新しいバージョンのLTSSリポジトリが存在しないため発生します。

この問題を解決するには、アップグレードする前にLTSS拡張機能を無効にします。

  1. LTSS拡張機能が有効になっているかどうかを確認します。 

    > sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

  2. 先に述べたSUSEConnect出力からのコマンドを使用して、LTSS拡張機能を無効にします。 

    > sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

  3. zypper lrでLTSSリポジトリが存在していないことを確認します。

3.7 PostgreSQLデータベースのマイグレート

 

SUSE Linux Enterprise Server 15 SP4は、PostgreSQLデータベースのバージョン13、14とともに出荷されます。デフォルトはバージョン14です。ただし、古いバージョンのSUSE Linux Enterprise Serverからアップグレードするためのレガシモジュールにはバージョン13が含まれます。

データベースのマイグレーション作業が必要であることから、自動アップグレードプロセスはありません。そのため、あるバージョンから別のバージョンへの切り替えは手動で行う必要があります。

マイグレーションプロセスは、pg_upgradeコマンドで行います。このコマンドは、従来のdumpとreloadコマンドに代わる方式です。「dump & reload」方式と比べてpg_upgradeの方がマイグレーション時間が短くなります。

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

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

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

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

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

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

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

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

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

    • コマンドpg_upgradeを含むパッケージpostgresql13-contribをインストールします。

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

      VACUUM FULL

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

    # /usr/sbin/rcpostgresql stop

    あるいは、 

    # systemctl stop postgresql.service

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

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

    # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

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

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

    あるいは、 

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

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

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

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

  6. ユーザのpostgresとしてマイグレーションプロセスを開始します。 

    # su - postgres
postgres > pg_upgrade \
 --old-datadir "/var/lib/pgsql/data.old" \
 --new-datadir "/var/lib/pgsql/data" \
 --old-bindir "/usr/lib/postgresql12/bin/" \
 --new-bindir "/usr/lib/postgresql13/bin/"

  7. 新しいデータベースインスタンスを次のいずれかを使用して開始します。 

    # /usr/sbin/rcpostgresql start

    あるいは、 

    # systemctl start postgresql.service

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

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

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

    # zypper search -s postgresql12| xargs zypper rm -u
# rm -rf /var/lib/pgsql/data.old

データベースのアップグレード、または論理レプリケーションなどの代替方法の使用の詳細については、PostgreSQLの公式ドキュメント(https://www.postgresql.org/docs/13/upgrading.html)を参照してください。

3.8 MySQLまたはMariaDBデータベースのマイグレート

 

SUSE Linux Enterprise 12では、SUSEは、MySQLからMariaDBに切り替えました。アップグレードを開始する前に、データベースのバックアップを取得することを強くお勧めします。

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

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

    # mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql

    デフォルトでは、mysqldumpは、INFORMATION_SCHEMA、またはperformance_schemaデータベースをダンプしません。詳細については、https://mariadb.com/kb/en/mariadb-dumpmysqldump/を参照してください。

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

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

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

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

    # systemctl start mariadb

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

    # systemctl enable mariadb

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

    # mariadb -u root -p

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

 

セキュリティ対策として、MD5ベースの証明書はJavaでサポートされなくなりました。MD5として作成された証明書を持っている場合、次の手順で証明書を再作成してください。

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

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

    # openssl genrsa -out server.key 1024

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

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

    # openssl req -new -key server.key -out server.csr

  4. 証明書を自己署名します。 

    # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

  5. PEMファイルを作成します。 

    # cat server.key server.crt > server.pem

  6. ファイルserver.crt、server.csr、server.key、およびserver.pemを鍵が見つかったそれぞれのディレクトリに配置します。たとえばTomcatの場合、このディレクトリは/etc/tomcat/ssl/です。

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

 

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

3.11 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の場合、次のコマンドを実行します。 

      > sudo suse_register -E
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*
> sudo rm -f /var/cache/SuseRegister/*
> sudo rm -f /etc/suseRegister*
> sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
> sudo rm -f /etc/zmd/deviceid
> sudo rm -f /etc/zmd/secret

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

      > sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*

  3. SMTサーバにログインします。

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

    > sudo smt-list-registrations

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

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

    > sudo smt-delete-registration -g UNIQUE_ID

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

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

    > sudo smt-list-registrations

3.12 SLE 12から15へAutoYaSTプロファイルの変更

 

AutoYaSTプロファイルのマイグレート方法については、Appendix D, Differences between AutoYaST profiles in SLE 12 and 15を参照してください。

3.13 登録管理ツール(SMT)サーバのアップグレード

 

SMTを実行しているサーバには特別なアップグレード手順が必要です。『Repository Mirroring Tool Guide』のChapter 3, Migrate from SMT to RMTを参照してください。

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

 

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

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

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

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

 

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

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