この数年間、お客様のフィードバックに基づく機能改善の必要性が明らかになり、SUSEでは、ユーザにアップデートを提供する方法に関してさまざまな変更を実施しました。

上記の一部の側面は、図7.1「メンテナンス配信の進化(SLEDにも適用)」で説明されています。

図7.1 メンテナンス配信の進化(SLEDにも適用)¶

弊社の製品のライフサイクルは10年です。そのうち7年間は一般サポート、3年間は拡張サポートが適用されます。主要リリースは4年ごと、サービスパックは18カ月ごとに作成されます。Long Term Service Pack Support(長期サービスパックサポート)は、延長された期間つまり延長された主要リリースライフサイクルをサポートします(図7.2「長期サービスパックサポート」参照)。

図7.2 長期サービスパックサポート¶

Long Term Service Pack Supportには、アクティブな購読(標準または優先のいずれか)が必要です。このサポートは、L1やL2の購読約款には影響しません。セキュリティ更新は、「プロアクティブに」処理されます。これらは、非ユーザ主導の更新であり、重大な脆弱性やカーネルでのローカルルートエクスプロイトなどのルートエクスプロイトの修正をユーザ介入なしで直接実行します。

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

以前の保守モデルでは、SUSE Linux Enterprise Serverには、SLES11-SPx-PoolとSLES11-SPx-Updatesという2つのチャネルが割り当てられていました。SPx+1へのオンラインマイグレーションの過程で、これらのチャネルは一時的にSLES11-SPx-Onlineに置き換えられていました。

SUSE Linux Enterprise SP2では、新しい保守モデルの利点をサポートするために、チャネルレイアウトが変更されました。表7.2「SUSE Linux Enterprise 11 SP1、SP2、SP3のチャネルレイアウト」には、SP1からSP3までのすべてのチャネルのリストが含まれています。

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

更新の前に、既存の設定ファイルを別個のメディア(テープデバイス、リムーバブルハードディスクなど)にコピーして、データをバックアップします。主に、/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 Host Serverとして機能している場合、更新の前には、実行中のすべてのVM Guestを正しくシャットダウンするようにします。そうでないと、更新後にゲストにアクセスできなくなる可能性があります。

バージョン固有の要件については、アップデート製品に付属しているリリースノートを参照してください。リリースノートには、アップグレード手順に関する追加情報が含まれています。

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

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

7.5.1.1. 要件¶

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

製品登録

アップデートチャネルに接続できるようになるには、製品を登録する必要があります。そうでない場合は、YaSTのNovell Customer Center設定モジュール、またはsuse_registerコマンドラインツールを実行して、登録を開始します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

こうしたバグ修復や機能にか案する情報が保存されている場所は数多くあります。

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

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

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

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

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

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

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

これらのスクリプトは、/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を使用する必要があります。