19 SUSE Linux Enterpriseのアップグレード #
SUSE® Linux Enterprise (SLE)では、既存のシステムを新しいバージョンにアップグレードできます。新たにインストールする必要はありません。ホームディレクトリ、データディレクトリ、システム設定などの既存のデータは、そのまま保持されます。CD/DVDドライブから、またはネットワーク上にある中央のインストールソースからアップデートできます。
この章では、DVD、ネットワーク、自動化プロセス、SUSE Managerなどを使用して、SUSE Linux Enterprise システムを手動でアップグレードする方法について説明します。
19.1 SLE SP5へのサポートされているアップグレードパス #
クロスアーキテクチャアップグレードは「サポートされません」。たとえば、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で管理されている場合、アップグレード手順は管理インタフェースで開始する必要があります。詳細については、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.bakroot #
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に切り替えました。アップグレードを開始する前に、データベースのバックアップを取得することを強くお勧めします。
データベースマイグレーションを実行するには、次の手順を実行します。
ご使用のSUSE Linux Enterprise 11マシンにログインします。
ダンプファイルを作成します。
root #
mysqldump
-u root -p --all-databases > mysql_backup.sqlデフォルトでは、
mysqldump
は、INFORMATION_SCHEMA
、またはperformance_schema
データベースをダンプしません。詳細については、https://dev.mysql.com/doc/refman/5.5/en/mysqldump.htmlを参照してください。ダンプファイル、環境設定ファイル、
/etc/my.cnf
、およびディレクトリ、/etc/mysql/
を後で調べることができるように(インストールのためではありません)安全な場所に保存します。アップグレードを実施します。アップグレードが終わっても、前の環境設定ファイル、
/etc/my.cnf
は前のままです。新しい設定は、/etc/my.cnf.rpmnew
ファイルで確認できます。必要に応じて、MariaDBデータベースを設定します。以前の設定ファイルとディレクトリを使わないでください。これらは、リマインダとして使用し、活用するだけです。
MariaDBサーバを起動して確認してください。
root #
systemctl
start mysqlブートのたびにMariaDBサーバを起動する場合は、そのサービスを有効にします。
root #
systemctl
enable mysqlMariaDBが適切に稼働していることを、データベースに接続して確認します。
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からアップグレードする場合、postgresql94
がアンインストールされ、PostgreSQLのより高いバージョンにデータベースをマイグレーションするために使用できません。したがって、この場合、システムをアップグレードする「前に」PostgreSQLデータベースをマイグレートしてください。
以下の手順は、バージョン9.6から10へのデータベースマイグレーションについて説明しています。スタートまたはターゲットとして異なるバージョンを使用する場合は、それに応じてバージョン番号を置き換えます。
データベースマイグレーションを実行するには、次の手順を実行します。
以下の前提条件が満たされていることを確認します。
満たされていない場合、保守アップデートで、古いPostgreSQLバージョンを最新リリースにアップグレードします。
既存のデータベースのバックアップを作成します。
新規のPostgreSQLのメジャーバージョンのパッケージをインストールします。SLES12 SP5の場合、これは postgresql10-server およびそれが依存するすべてのパッケージのインストールを意味します。
パッケージ postgresql10-contrib をインストールします。これには、
pg_upgrade
コマンドが含まれています。ご使用のPostgreSQLデータ領域(デフォルトでは
/var/lib/pgsql/data
)に十分な空き容量があることを確認します。容量が厳しい場合、次のSQLコマンドをデータベースごとに実行して、サイズを縮小します(長時間要する場合があります)。VACUUM FULL
以下のいずれかでPostgreSQLサーバを停止します。
root #
/usr/sbin/rcpostgresql
stopまたは
root #
systemctl stop postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
古いデータディレクトリの名前を変更します。
root #
mv
/var/lib/pgsql/data /var/lib/pgsql/data.old新規のデータベースインスタンスを初期化します。
initdb
を使用して手動で実行するか、PostgreSQLを起動、停止することで自動的に実行します。root #
/usr/sbin/rcpostgresql
startroot #
/usr/sbin/rcpostgresql
stopまたは
root #
systemctl start postgresql.serviceroot #
systemctl stop postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
古いバージョンの設定ファイルを変更している場合は、これらの変更を新しい設定ファイルに転送することを検討します。これは、
postgresql.auto.conf
、postgresql.conf
、pg_hba.conf
、およびpg_ident.conf
ファイルに影響する場合があります。これらのファイルの古いバージョンは/var/lib/pgsql/data.old/
にあり、新しいバージョンは/var/lib/pgsql/data
で見つけることができます。古い設定ファイルをコピーすることは推奨されないことに注意してください。コピーすることにより、新しいオプション、新しいデフォルト、および変更されたコメントが上書きされる場合があるためです。
ユーザの
postgres
としてマイグレーションプロセスを開始します。root #
su - postgres postgres >pg_upgrade
\ --old-datadir "/var/lib/pgsql/data.old" \ --new-datadir "/var/lib/pgsql/data" \ --old-bindir "/usr/lib/postgresql96/bin/" \ --new-bindir "/usr/lib/postgresql10/bin/"新しいデータベースインスタンスを次のいずれかを使用して開始します。
root #
/usr/sbin/rcpostgresql
startまたは
root #
systemctl start postgresql.service(アップグレードのスタートバージョンとして使用するSLEバージョンによって異なる)。
マイグレーションが成功したかどうか確認します。テストのスコープは使用事例によって異なります。この手順を自動化する一般的なツールはありません。
すべての古いPostgreSQLパッケージと古いデータディレクトリを削除します。
root #
zypper
search -s postgresql96 | xargs zypper rm -uroot #
rm
-rf /var/lib/pgsql/data.old
19.3.6 JavaアプリケーションのMD5以外のサーバ証明書を作成します。 #
SP1からSP2に更新するときに、MD5ベースの証明書はセキュリティ修正の一環として無効にされました。MD5として作成された証明書を持っている場合、次の手順で証明書を再作成してください。
端末を開いて、
root
としてログインします。秘密鍵を作成します。
root #
openssl
genrsa -out server.key 1024より強力な鍵が必要な場合、
1024
を4096
などの大きい数に置き換えます。証明書署名要求(CSR)を作成します。
root #
openssl
req -new -key server.key -out server.csr証明書を自己署名します。
root #
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crtPEMファイルを作成します。
root #
cat
server.key server.crt > server.pemファイル
server.crt
、server.csr
、server.key
、およびserver.pem
を鍵が見つかったそれぞれのディレクトリに配置します。たとえばTomcatの場合、このディレクトリは/etc/tomcat/ssl/
です。
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サーバからマシンの登録を解除します。その後、アップグレードプロセスを再開します。
クライアントマシンにログインします。
次のステップは、クライアントの現在のオペレーティングシステムによって異なります。
SUSE Linux Enterprise 11の場合、次のコマンドを実行します。
tux >
sudo
suse_register -Etux >
sudo
rm -f /etc/SUSEConnecttux >
sudo
rm -rf /etc/zypp/credentials.d/*tux >
sudo
rm -rf /etc/zypp/repos.d/*tux >
sudo
rm -f /etc/zypp/services.d/*tux >
sudo
rm -f /var/cache/SuseRegister/*tux >
sudo
rm -f /etc/suseRegister*tux >
sudo
rm -f /var/cache/SuseRegister/lastzmdconfig.cachetux >
sudo
rm -f /etc/zmd/deviceidtux >
sudo
rm -f /etc/zmd/secretSUSE Linux Enterprise 12の場合、次のコマンドを実行します。
tux >
sudo
SUSEConnect --de-registertux >
sudo
SUSEConnect --cleanuptux >
sudo
rm -f /etc/SUSEConnecttux >
sudo
rm -rf /etc/zypp/credentials.d/*tux >
sudo
rm -rf /etc/zypp/repos.d/*tux >
sudo
rm -f /etc/zypp/services.d/*
SMTサーバにログインします。
すべてのクライアントの登録を一覧表示して、クライアントが正常に登録解除されているかどうかを確認します。
tux >
sudo
smt-list-registrationsクライアントのホスト名がまだこのコマンドの出力に一覧表示されている場合は、最初の列からクライアントの
固有のID
を取得します。(クライアントは複数のIDで一覧表示されている場合があります。)このクライアントの登録を削除します。
tux >
sudo
smt-delete-registration -g UNIQUE_IDクライアントが複数のIDで一覧表示されている場合は、その固有のIDのそれぞれについてこのステップを繰り返します。
次を再実行して、クライアントが正常に登録解除されているかどうかを確認します。
tux >
sudo
smt-list-registrations
19.3.9 ディスク容量 #
ソフトウェアは、バージョンが上がるたびに増加する傾向があります。そのため、更新する前に、使用可能名パーティションの容量を調べてください。ディスク容量が不足する可能性がある場合は、データをバックアップしてから、パーティションのサイズを変更するなどして、使用可能な容量を増やしてください。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。
更新手順の実行中に、YaSTは空きディスク容量を確認し、インストールで使用可能な容量を超える可能性がある場合は、ユーザに警告を表示します。その場合、更新を実行すると、「システムが使用できなくなる」ことがあります。操作の内容を(事前のテストによって)確実に把握している場合にのみ、この警告をスキップして更新を続行できます。
19.3.9.1 Btrfs以外のファイルシステムにおける空きディスク容量の確認 #
df
コマンドを使用して、使用可能なディスク容量を表示できます。たとえば、例19.1「df -h
の出力例」では、ルートパーティションは/dev/hda3
です(/
としてマウントされています)。
df -h
の出力例 #Filesystem Size Used Avail Use% Mounted on /dev/sda3 74G 22G 53G 29% / tmpfs 506M 0 506M 0% /dev/shm /dev/sda5 116G 5.8G 111G 5% /home /dev/sda1 44G 4G 40G 9% /data
19.3.9.2 Btrfsファイルシステムの空きディスク容量の確認 #
マシンでBtrfsをルートファイルシステムとして使用している場合、十分な空き容量があることを確認します。多くの場合、アップグレードには、新しいスナップショット用に、現在のルートファイルシステムと同じディスク容量が必要になります(/.snapshot
がない場合)。使用可能なディスク容量を表示するには、次のコマンドを使用します。
root #
df
-h /
ほかのすべてのマウント済みパーティションでも、使用可能な容量を確認します。効果が実証されている推奨事項は次のとおりです。
Btrfsを含めてすべてのファイルシステムで、大きなRPMをダウンロードし、インストールできるだけの空きディスク容量が必要です。古いRPMが使用している容量は、新しいRPMのインストール後にのみ解放されます。
スナップショットがあるBtrfsの場合、現在のインストールで使用している容量と同じだけの空き容量が最低でも必要です。現在のインストール環境の2倍の空き容量を確保することを推奨します。
十分な空き容量がない場合、
snapper
を使用して古いスナップショットを削除することができます。root #
snapper
listroot #
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/displaymanager
でDISPLAYMANAGER_STARTS_XSERVER
の設定を次のように変更します。
DISPLAYMANAGER_STARTS_XSERVER="yes"