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

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

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

  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.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からのアップグレード

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.conf、postgresql.conf、pg_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ファイルシステムでの使用済みおよび使用可能なスペースを確認する方法の詳細については、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プロファイルのマイグレート方法については、Appendix D, Differences between AutoYaST profiles in SLE 12 and 15を参照してください。

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

 

SMTを実行しているサーバには特別なアップグレード手順が必要です。『Repository Management 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

更新が正常に完了した後にこの機能を再アクティブ化するには、コメント記号を削除します。マルチバージョンサポートの詳細については、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"