リリースノートには、旧リリースのSUSE Linux Enterpriseからの変更点に関する追加情報が記載されています。特定のハードウェアやセットアップについて特別な考慮が必要かどうか、使用している特定のソフトウェアパッケージのどれに大幅な変更があったか、およびこのセクションに示す一般的な推奨事項のほかにどのような予防措置を講じる必要があるかについて、リリースノートで確認してください。リリースノートには、リリース直前になって判明したためマニュアルに記載できなかった情報と既知の問題も記載されています。

SUSE Linux Enterprise Serverの最新情報を含むリリースノートの最新バージョンのドキュメントは、http://www.suse.com/doc/sles12/#startでオンラインで読むことができます。

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

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

更新を開始する前に、ルートパーティションの記録をとります。df /コマンドは、ルートパーティションのデバイス名リストを表示します。たとえば、例7.1「df -hの出力例」に示すように、書き留めておくルートパーティションは、/dev/hda3です(/としてマウントされています)。

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

ソフトウェアは、バージョンが上がるたびに「増加する」傾向があります。そのため、更新する前に、はじめにdfコマンドで、利用できるパーティションの容量を調べてください。ディスク容量が不足していると思われる場合は、システムの更新とパーティション再設定を行う前に、データをバックアップしておきます。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。

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

オンラインアップデートを実行するには、次の要件を満たす必要があります。必ず、7.3項 「アップデートのための一般的な準備」も読んでください。

重要: 完全なオンラインマイグレーションを常に実行

オンラインマイグレーションは常に、最初から最後まで完全に実行する必要があります。オンラインマイグレーションが中断された場合、システムは破損され回復不能な状態になります。

オンラインマイグレーションによるシステムのアップデートは、稼働中のシステム内から実行されます。アップデートの完了後、1度だけ再起動の必要があります。

7.4.4.1 要件 #

オンラインアップデートを実行するには、次の要件を満たす必要があります。必ず、7.3項 「アップデートのための一般的な準備」も読んでください。

製品登録

アップデートリポジトリに接続できるようにするには、製品を登録する必要があります。まだ登録していない場合は、YaSTのSUSEカスタマーセンターの環境設定モジュール、またはsuse_registerコマンドラインツールを実行して、登録を開始します。

オンラインアップデートの実行

現在インストールされているバージョンに最新のパッチがインストールされていることを確認します。オンラインマイグレーションの前に、オンラインアップデートを実行します。グラフィカルインタフェースを使用して、YaSTオンラインアップデートまたはアップデータアプレットを起動します。コマンドラインで、次のコマンドを実行します(最後のコマンドは2回実行する必要があります)。

zypper ref -s
zypper update -t patch
zypper update -t patch

必要に応じて、システムを再起動します。

詳細については、第1章 YaSTオンラインアップデート, 管理ガイドまたは項 「Zypperによるソフトウェアの更新」, 第6章 コマンドラインツールによるソフトウェアの管理, 管理ガイドを参照してください。オンラインアップデートツールの

サードパーティのソフトウェア

セットアップにサードパーティのソフトウェアまたはアドオンソフトウェアが含まれている場合は、別のコンピュータでこのプロシージャをテストして、依存関係が更新によって破損していないかどうか確認してください。

重要: 完全なオンラインマイグレーションを常に実行

オンラインマイグレーションは常に、最初から最後まで完全に実行する必要があります。オンラインマイグレーションが中断された場合、システムは破損され回復不能な状態になります。

7.4.4.2 YaST Wagonによるオンラインマイグレーション #

注記

YaST Wagonによるオンラインマイグレーションは、SUSE Linux Enterprise Server 12より前のバージョンでのみ利用可能です。

1. すべての要件が満たされている場合(7.4.4.1項 「要件」を参照)、トレイのアップデートアプレットには、配布アップグレードが使用可能であることを示すメッセージが表示されます。これをクリックして、YaST Wagonを起動します。または、コマンドラインからrootとして/usr/sbin/wagonを実行します。

2. ようこそダイアログの次へを選択して確定します。

3. Wagonでは、要件が満たされていない(必要な保守アップデートが使用可能なのに、まだインストールされていない)ことが見つかったら、自動的なセルフアップデートが実行されます。この場合再起動が必要になります。画面の指示に従って操作します。

4. 次のダイアログで、アップデート方法を選択します。デフォルトの設定を使用するには、Customer Centerを選択します(推奨)。

   オンラインマイグレーションに使用するソフトウェアリポジトリを手動で選択するには、Custom URL (カスタムURL)をクリックします。リポジトリのリストが表示され、リポジトリを手動で有効化、無効化、追加、または削除できるようになります。SP2アップデートソースを追加します。これは、SP2インストールメディアか、SP2-CoreおよびSP2-Updatesリポジトリのいずれかの可能性があります。OKをクリックして、Update Method (アップデート方法)ダイアログに戻ります。

   アップデートプロセスによって発生したリポジトリ設定に対する変更を確認する必要がある場合は、自動リポジトリ変更の確認を選択します。

   次へで続行します。

5. システムが再登録されます。このプロセスの実行中に、SP2-CoreおよびSP2-Updatesリポジトリがシステムに追加されます(詳細については、7.7.2項 「リポジトリモデル」を参照してください)。リポジトリが追加されたことを確認します。

6. Update Method (アップデート方法)ダイアログで自動リポジトリ変更の確認を選択した場合、リポジトリのリストが表示され、リポジトリを手動で有効化、無効化、追加、または削除できるようになります。終了したら、OKで続行します。

7. マイグレーションタイプを選択します。

   完全マイグレーション

   すべてのパッケージを最新のSP2レベルに更新します。

   最小マイグレーション

   パッケージの最小限のセットを最新のSP2レベルに更新します。

   詳細をクリックして、アップグレードに使用するリポジトリを手動で選択します。

   選択内容を確認します。

8. 配布アップグレード設定画面が開き、アップデート設定の概要が表示されます。次のセクションを使用できます。

   アドオン製品

   ここでは、SUSE Linux Enterprise Serverのアドオン製品か、サードパーティの製品を追加できます。

   アップデートオプション

   アップデート中に実行されるアクションがリストされます。インストールの前にすべてのパッケージをダウンロードするのか(デフォルト、推奨)、パッケージを1つずつダウンロードしてインストールするのかを選択できます。

   パッケージ

   アップデートの統計概要。

   バックアップ

   バックアップオプションを設定します。

   次へおよびStart The Updateをクリックして続行します。

   

   重要: オンラインマイグレーションを中止する

   この画面でStart The Updateをクリックする前と、それ以前のすべての画面では、オンラインマイグレーションを安全に中止することができます。Abort (中止)をクリックしてアップデート手順を中止し、YaST Wagonを開始する前の状態にシステムを戻します。画面の指示に従って、Wagonを中止する前に再登録を実行し、SP2リポジトリをシステムから削除します。

9. アップデート手順の過程では、次のステップが実行されます。

   1. パッケージが更新されます。

   2. システムが再起動されます(OKを選択します)。

   3. 新しく更新されたシステムが再登録されます。

10. システムがサービスパック2に正しく更新されます。

オンラインマイグレーション(詳細については7.4.4項 「オンラインマイグレーション」を参照)の代わりとして、インストールソース(DVDまたはネットワークインストールソース)からブートすることでシステムをアップデートできます。アップデートは、通常のインストールと同じように開始されます。

サービスパック2 ISOイメージは、http://download.suse.com/から取得できます。これをDVDに書き込むか、14.2項 「インストールソースを保持するサーバのセットアップ」の説明に従ってネットワークインストールソースを準備します。

SUSEアップデートサーバからクライアントシステムごとにアップデートをダウンロードする代わりに、SUSE Linux Enterprise用のサブスクリプション管理ツール(SMT)を使用して、アップデートをローカルサーバにミラーリングすることもできます。

このツールはクライアント登録用のSUSEカスタマーセンタープロキシ、およびソフトウェアアップデートリポジトリとして機能します。http://www.suse.com/doc/smt11/にあるSMTのマニュアルに、機能の概要と実装方法の説明が記載されています。

SUSE Managerは、SUSE Linux Enterpriseクライアントに対するアップデート、パッチ、およびセキュリティ修正を提供するためのサーバソリューションです。これには、一連のツールと、管理タスク用のWebベースのユーザインタフェースが付属しています。

http://www.suse.com/doc/suse_manager/にあるSUSE Managerのマニュアルに、機能の概要とサーバおよびクライアントのセットアップ方法の説明が記載されています。

インストールソース(ローカルDVDまたはネットワークインストールソースのいずれか)からブートして、フレッシュインストールを実行する場合と同じようにシステムをアップグレードできます。ブート画面で［Install (インストール)］の代わりに［Upgrade (アップグレード)］を選択してシステムをアップグレードします。

自動マイグレーションを実行するには、次の手順に従います。

multi-updateを実行します。このコマンドは、chroot環境でzypperを実行し、もう一方のシステムを更新します。どちらのシステムがアクティブかは重要でありません。そのブートメニューは、ブート時にデフォルトとして表示されます。

更新したシステムのブートローダが更新後に破損している場合は、「アクティブ」フラグを変更して、もう一方のシステムのルートパーティション用に設定し、そのシステムをブートできるようにする必要があります。

更新したシステムがまったくブートしない場合は、ブートローダメニューにアクセスしてもう一方のシステムを選択する必要があります。

GRUB 2の詳細については、第12章 ブートローダGRUB 2, 管理ガイドを参照してください。

ルートパティションは、パーティション名またはIDによってマウントするか、その他の方法でマウントする必要があります。パーティションUUIDやラベルによるマウントはサポートされていません。

詳細については、multi-update-toolsパッケージに同梱されている/usr/share/doc/packages/multi-update-tools/READMEを参照してください。

拡張サポートレベルの範囲は、10年目から13年目までになります。これらのサポートレベルには、継続されるL3エンジニアリングレベルの診断とリアクティブな重大なバク修正が含まれます。これらのサポートレベルでは、重要でないカーネルでのローカルルートエクスプロイトなどのルートエクスプロイトに対しては、ユーザ介入なしで直接実行可能な更新をプロアクティブにサポートします。さらに、限られたパッケージ除外リストを使用して、既存のワークロード、ソフトウェアスタック、およびハードウェアをサポートします。概要については、表7.1「セキュリティ更新とバグの修正」を参照してください。

リポジトリレイアウトは製品ライフサイクルに対応しています。表7.2「SUSE Linux Enterprise 11 SP2とSP3、およびSUSE Linux Enterprise 12のリポジトリレイアウト」に、SUSE Linux Enterprise 11 SP2～SUSE Linux Enterprise 12のすべてのリポジトリのリストを示します。

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
    SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
    SLES11-SP2-Core SLES11-SP2-Updates \
    SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
    SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
    https://nu.novell.com/repo/\$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

アップストリームの開発者は、自分が開発するソフトウェアを前進させることを念頭に置いています。多くの場合、バグの修正と新機能の導入が組み合わせられますが、その新機能は詳細なテストをまだ受けていないために、新しいバグを生み出す可能性があります。

配布物の開発者としては、次のものを見分けることが重要です。

多くの場合、パッケージがリリースされた配布物の一部になったら、配布物の開発者はアップストリームでのすべての変更を追うことはしません。通常は、最初にリリースされたアップストリームバージョンから離れずに、アップストリームの変更に基づいてパッチを作成してバグを修正します。こうした一連の処理はバックポートと呼ばれています。

一般的に、配布物の開発者が新しいバージョンのソフトウェアを導入するのは、次の2つの場合のみです。

SUSEでは、エンタープライズソフトウェアに対する数多くの考慮事項のバランスをうまく取るために、広い範囲でバックポートを使用しています。こうした考慮事項のうち最も重要なものは次のとおりです。

一般的なポリシールールとしては、当社のエンタープライズ製品に、パッケージの新しいアップストリームバージョンは導入されないことになっています。ただしこのルールは絶対的なものではありません。限られたクラスのパッケージ(特定のウィルス対策ソフトウェア内)では、品質確保の観点から選ばれた保守的なアプローチよりも、セキュリティに関する考慮事項の方が重視されます。こうしたクラスのパッケージでは、時として、エンタープライズ製品ラインのリリース済みバージョンに、新しいバージョンが導入されることがあります。

その他のタイプのパッケージについても、バックポートではなく新しいバージョンの導入が選択される場合があります。バックポートの作成が経済的に不可能な場合や、新しいバージョンの導入に対する非常に妥当な技術的な理由が存在する場合などがこれに該当します。

バックポートが実行されているために、SUSEパッケージに特定の問題の修正が含まれているのか、または特定の機能が追加されているのかを、バージョン番号を単純に比較して判断することはできません。バックポートでは、SUSEパッケージのバージョン番号のアップストリーム部分は、単にSUSEパッケージの基となっているアップストリームバージョンを示しているだけです。ここには、対応するアップストリームリリースには存在しないけれどもSUSEパッケージにはバックポートされている修正や機能が含まれている可能性があります。

バックポートが関係する場合にバージョン番号のこの限られた値が問題を引き起こす可能性がある、1つの特定の領域として、セキュリティスキャンツールの使用が挙げられます。セキュリティの脆弱性スキャンツール(または、それらのツールによる特定のテスト)の中には、単にバージョン情報のみに基づいて機能するものがあります。したがって、これらのツール/テストでは、バックポートが関係している場合に「false positive」 (実際は脆弱ではないのに、ソフトウェアに脆弱な部分が見つかったというクレーム)が生成される傾向があります。セキュリティスキャンツールによるレポートを評価する場合は、エントリがバージョン番号に基づくものなのか、脆弱性が本当に存在するかどうかに関する実際のテストに基づくものかを、常に調査する必要があります。

バックポートされたバグ修正や機能に関する情報が保存されている場所は数多くあります。

これらのスクリプトは、/var/lib/YaST2/wagon/hooks/ディレクトリで見つけることができます。想定されるスクリプト名の形式は、step_seq_prefix_nameです。各文字列は次のような意味になります。

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

スクリプトは終了値0を返す必要があります。失敗した(終了値がゼロ以外の)場合は、Wagonにエラーメッセージが表示され、スクリプトを再起動するか、失敗を無視(別のスクリプトで続行)するか、現在のステップおよびステージのフックを完全にキャンセルすることができます。

フックスクリプトは何度も実行される可能性がある(Wagonのダイアログを行き来しているうちに、Wagonそのものが再起動したり、マイグレーションワークフロー内で一部のステップが複数回実行される可能性もある)ので、スクリプトはその事実に対処する必要があります(アクションを実行する必要があるのか、アクションはすでに実行済みなのか、単純な一時的なスタンプファイルを作成できるのか、そうでなければ複数回の実行を正しく解決できるのかを、最初に確認することができます)。

一部のフックはオプションです(以前の結果またはユーザ選択の値に依存しているため)。一部のフックは複数回呼び出されるので注意が必要です(たとえば、登録はマイグレーションの前後に呼び出されます)。次に、サポートされているフック(ステップ名)を実行順に並べたリストを示します。

ユーザがマイグレーションを中止したときに呼び出される、特別な中止のフックがあります。これらのフックはマイグレーションワークフロー内の任意のステップで呼び出すことができるので、実行順序は保証できません。他のフックの結果に依存している場合、スクリプトで現在の状態をチェックする必要があります。

これらのフックは、Wagonそのものが再起動されると常に呼び出されます。

フックのリストはかなり大きなものですが、その多くは特別な事例で意味をなすものです。通常の使用例では、次のようなフックが優先的に使用されます。

古いバージョンのWagonでは、2つのフックスクリプトのみがサポートされていました。/usr/lib/YaST2/bin/wagon_hook_initと/usr/lib/YaST2/bin/wagon_hook_finishです。問題は、フックとして実行できるスクリプトは1つだけで、フックを直接PRMパッケージに配置できないことでした。

これらの古いフックスクリプトは、後方互換性のために新しいバージョンのWagonでもサポートされていますが、廃止されたフックの変わりに、新しいフックのbefore_initとbefore_exitを使用する必要があります。