Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
適用先 SUSE Linux Enterprise Server 11 SP4

7 SUSE Linux Enterpriseのアップデート

SUSE® Linux Enterprise (SLE)には、完全な再インストールを実行せずに既存のシステムを新しいバージョンに更新できるオプションがあります。新たにインストールする必要はありません。ホームディレクトリ、システム設定などの既存のデータは、そのまま保持されます。製品のライフサイクル中は、サービスパックを適用することで、システムセキュリティを向上させ、ソフトウェアの不具合を修正し、新機能にアクセスすることができます。CD/DVDドライブから、またはネットワーク上のインストールソースからインストールします。

7.1 用語集

この章では、いくつかの用語を使用します。それらの情報を理解するには、以下の定義をお読みください。

バックポート

バックポートとは、新しいバージョンのソフトウェアによる特定の変更内容を採用し、それを古いバージョンに適用することを意味します。最も一般的な使用事例は、古いソフトウェアコンポーネントのセキュリティホールの修正です。通常は、拡張機能や(頻度は低いものの)新機能を提供するための保守モデルの一部にもなります。

Deltarpm

delatrpmは、2つの定義されたパッケージバージョンのバイナリ差分のみで構成されているので、ダウンロードサイズは最小です。インストールの前に、RPMのフルパッケージがローカルコンピュータ上で再構築されます。

ダウンストリーム

オープンソースワールドにおけるソフトウェア開発方法のメタファーです(アップストリームと対比)。「ダウンストリーム」という用語は、アップストリームからのソースコードを他のソフトウェアと統合し、エンドユーザが使用するためのディストリビューションを構築する、SUSEのような人や組織を指しています。つまり、ソフトウェアは開発者からインテグレータを介して、エンドユーザーまで、ダウンストリーム(下向き)に流れていきます。

オンラインマイグレーション

それぞれのパッチをインストールするために、(インストールメディアではなく)オンラインアップデートツールを使用して、サービスパック(SP)への更新を行うことです。インストールシステムのすべてのパッケージを最新状態にアップデートします(SP3およびSP2アップデートを含む)。

パッケージ

パッケージは、rpm形式で圧縮されたファイルで、特定のプログラムのすべてのファイルが格納されています。環境設定、サンプル、ドキュメントなどのオプションコンポーネントも含まれます。

パッチ

パッチは、1つ以上のパッケージから成り、deltarpmで適用されることがあります。また、まだインストールされていないパッケージへの依存関係を導入することもあります。

サービスパック(SP)

複数のパッチを組み合わせて、インストールまたは展開しやすい形式にします。サービスパックには番号が付けられ、通常、プログラムのセキュリティ修正、更新、アップグレード、または拡張機能が含まれます。

アップストリーム

オープンソースワールドにおけるソフトウェア開発方法のメタファーです(ダウンストリームと対比)。アップストリームという用語は、ソースコードとして配布されるソフトウェアの元のプロジェクト、作者、またはメンテナンス者を指しています。フィードバック、パッチ、拡張機能、その他の改良機能は、エンドユーザまたはコントリビュータからアップストリーム(上流)の開発者に流れていきます。開発者は、リクエストを組み込むのか却下するのか決定します。

プロジェクトメンバーがリクエストを組み込むように決定すると、それが新しいバージョンのソフトウェアに出現します。受け入れられたリクエストは、すべての関係者にメリットをもたらします。

リクエストが受け入れられない場合は、別の理由が考えられます。プロジェクトのガイドラインに準拠していない、無効である、すでに組み込まれている、プロジェクトに関係ないかロードマップ上に存在しないなどの中のいずれかの理由です。リクエストが受け入れられない場合、アップストリームの開発者にとっては、自分のパッチをアップストリームのコードと同期させる必要があるために困難が生じます。この操作は一般的には回避されますが、まだ必要な場合もあります。

アップデート

パッケージの新しいマイナーバージョンのインストール。

アップグレード

パッケージまたは配布の新しい主要バージョンのインストール。これにより新機能がもたらされます。

7.2 SUSE Linux Enterprise 11の保守モデル

SUSE Linux Enterprise 11の保守モデルでは、サービスパックの柔軟性と制御を組み合わせています。このモデルには、次の利点があります。

  • サービスパックが軽量化し、そのテストと展開が容易になります。

  • 旧バージョンとの共存を可能にする一方で、フルシステムをサポートします。

  • 選択的な機能拡張でサービスパック間のマーケットニーズに対処し、一般更新リポジトリ内におけるより多くの更新を可能にします。機能拡張の選択により、サービスパックの間隔が長期化するのを緩和します。

7.2.1 予備知識

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

  • SLES 9では、すべてのアップデートが収集されるアップデートリポジトリが1つしかなく、最新リリースのアップデートが唯一サポートされているだけでした。

  • SLES 10 SP1以降、SP固有のリポジトリという概念が導入されました。つまり、1つのサービスパックに対するすべてのアップデートが、1つの固有のリポジトリで提供されるようになったのです。Novell Customer Centerで直接登録した場合、新しいサービスパックにマイグレートしたユーザは、それ以前のリポジトリにはアクセスできなくなります。SMTまたはSUSE Managerのユーザは、これまでも現在も、すべてのSPチャネルを無料で購読できます。この変更の主な理由は、リリースされたサービスパックの検証を可能にし、お客様に対するマイグレーション窓口を用意するための6か月の重複期間(1つ前のサービスパックのサポート)という概念でした。これにより、古いSP内でメンテナンスとサポートが完全に継続されることになります。

  • SLES 11 GAとSLES 11 SP1は、SLES 10モデルの後継バージョンです。SLES 11 SP2により、以下で構成される新しいリポジトリモデルが導入されました。

    1. SLES 11 SP1アップデートリポジトリは、購読されたままです。SP2にも適用可能なすべてのアップデートは、SP1アップデートリポジトリにもリリースされるか、SP1アップデートリポジトリのみにリリースされています。つまり、ここには、ABIおよびAPIの互換性を保持しているすべてのアップデートが引き続き配信されています。

    2. SLES 11 SP2アップデートリポジトリには、(さまざまな理由で)SP1アップデートリポジトリには配信できない最新の革新的なアップデートのみが含まれています。これに加えて当社ではコアリポジトリを導入しました。これは、SP1とSP2のどちらのアップデートリポジトリにもリリースされなかったパッケージのギャップを提供するものです。

    3. SLES 11 SP4は、SLES 10と同様のチャネルモデルを持つことになります。このモデルは、特定のサービスパックを対象にしたアップデートを提供するための最も簡単で迅速な方法として受け入れられています。すべてのアップデートは、特別なアップデートチャネルを介して提供されます。お使いのマシンでは追加のチャネルが使用可能になりますが、古いチャネルは削除されます。

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

メンテナンス配信の進化(SLEDにも当てはまる)
図 7.1: メンテナンス配信の進化(SLEDにも当てはまる)

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

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

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

7.2.2 サポートレベル

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

表 7.1: セキュリティ更新とバグの修正
 

— 一般サポート —

拡張サポート

トピック

現在のSP

SP (n-1) 6ヶ月

SP (n-1) LTSS

6年目と7年目 LTSS

8、9、10年目 LTSS

L1/L2テクニカルサービス

先行保守

 

 

PLDPによるドライバ更新

  

先行セキュリティ更新

 

L3エンジニアリングサポート

バックポートあり

 

7.2.3 チャネルモデル

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

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

表 7.2: SUSE Linux Enterprise 11 SP1、SP2、およびSP3のチャネルレイアウト

タイプ

SLES

SLED

必要なチャネル

SP1

SLES11-SP1-Pool
SLES11-SP1-Updates

SP2

SLES11-SP1-Pool
SLES11-SP1-Updates
SLES11-SP2-Core
SLES11-SP2-Updates

SP3

SLES11-SP3-Pool
SLES11-SP3-Updates

SP4

SLES11-SP4-Pool
SLES11-SP4-Updates

SP1

SLED11-SP1-Pool
SLED11-SP1-Updates

SP2

SLED11-SP1-Pool
SLED11-SP1-Updates
SLED11-SP2-Core
SLED11-SP2-Updates

SP3

SLED11-SP3-Pool
SLED11-SP3-Updates

SP4

SLED11-SP4-Pool
SLED11-SP4-Updates

オプションチャネル

SP1

SLES11-SP1-Debuginfo-Pool
SLES11-SP1-Debuginfo-Updates

SP2

SLES11-SP2-Debuginfo-Core
SLES11-SP2-Debuginfo-Updates
SLES11-Extras
SLES11-SP2-Extension-Store

SP3

SLES11-SP3-Debuginfo-Core
SLES11-SP3-Debuginfo-Updates
SLES11-SP3-Extension-Store
SLES11-Extra

SP4

SLES11-SP4-Debuginfo-Pool
SLES11-SP4-Debuginfo-Updates
SLES11-Extra
SLES11-Security-Module

SP1

SLED11-SP1-Debuginfo-Pool
SLED11-SP1-Debuginfo-Updates

SP2

SLED11-SP2-Debuginfo-Core
SLED11-SP2-Debuginfo-Updates
SLED11-Extras
SLED11-SP2-Extension-Store

SP3

SLED11-SP3-Debuginfo-Core
SLED11-SP3-Debuginfo-Updates
SLED11-SP3-Extension-Store
SLED11-Extra

SP4

SLED11-SP4-Debuginfo-Pool
SLED11-SP4-Debuginfo-Updates

製品固有(例)

SLES11-WebYaST-SP2-Pool
SLES11-WebYaST-SP2-Updates
SLED11-MSI-Updates
必要なチャネルの説明
Core

パックされていないインストールメディアのサブセットで、SPxのコアだと見なされるパッケージのみが格納されます(パッケージ全体の約30%)。SPリポジトリには、SPとそのテーマ(ハードウェアイネーブルメントなど)に固有のパッケージのみが格納されます。SP2のみに存在します。

更新内容

保守によって更新されるのは、対応するCoreまたはPoolリポジトリ内のパッケージのみです。

Pool

インストールメディアからのすべてのバイナリRPMとパターン情報が格納され、ステータスメタデータをサポートします。

オプションチャネルの説明
Debuginfo-Pool, Debuginfo-Updates

これらのチャネルには、静的なコンテンツが格納されます。ただし、アップデートを受信するのはDebuginfo-Updatesチャネルのみです。問題の発生時にデバッグ情報を含むライブラリをインストールする必要がある場合は、これらのチャネルを有効にします。

Extension-Store

未使用です。(将来的な)アドオン製品用のパッケージを格納するためにサポートされています。SLES 11 SP4以降、Extension Storeチャネルは削除されます。

LTSS-Updates

Long Term Support Service (LTSS)を含むインストールの場合に、対応するPoolリポジトリ内のパッケージが保守によって更新されます。この特定のチャネルにはLTSS契約が必要です。

7.2.3.1 パッケージの起源

SUSE Linux Enterprise 11 SP3/SP4: SP3のインストールでは、SLES11-SP3-PoolとSLES11-SP3-Updatesという2つのチャネルのみが使用可能です。SP2からの以前のチャネルは表示されますが、有効にはなりません。これらの無効なチャネルは、特定のニーズを持つユーザのみが必要としています。

7.2.3.2 チャネルの操作

登録を行うと、システムが Customer Centerからチャネルを受信します。チャネル名はカスタマセンター内の特定のURIにマップされています(http://scc.suse.comを参照)。ご使用のシステムで使用可能なすべてのチャネルを一覧するには、次のようにzypperを使用します。

zypper repos -u

これにより、ご使用のシステムで使用可能なすべてのチャネルのリストが表示されます。チャネルごとに、エイリアス、名前、有効化どうか、リフレッシュされるかどうかといった情報がリストされます。オプション-uを使用すると、元となるURIも表示されます。

古いチャネル(SP1にあるものなど)を削除する場合は、zypper removerepoと、チャネルの名前を使用します。たとえば、SP1およびSP2の古いチャネルを削除するには、次のコマンドを使用します。

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

チャネルを再度追加する場合は、http://www.novell.com/nccにログインして、マイプロダクト › 資格情報のミラーの順に選択します。URIのリストが表示され、この製品リストにあるチャネルのみを追加することができます。たとえば、SP2 Extension Storeを追加する場合は、次のコマンドを使用します(1行で、バックスラッシュなし)。

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

7.3 SLE SP4へのサポートされているアップグレードパス

SLES 8、SLES 9、NLD 9のアップグレード

これらのバージョンからの直接的なアップグレードパスはサポートされていません。その代わりに、新しいインストールの実行を推奨します。

SUSE Linux Enterprise 10 (任意のサービスパック)からのアップグレード

SLES 10 GAおよびSPx、またはSLES 11 GAおよび SP1からSLES 11 SP3へのアップグレード方法はサポートされていますが、次のような中間アップグレード手順の実行が必要な場合があります。

  • SLES 10 GA -> SLES 10 SP1 -> SLES 10 SP2 -> SLES 10 SP3 -> SLES 10 SP4 -> SLES 11 SP3、または

  • SLES 11 GA -> SLES 11 SP1 -> SLES 11 SP2 -> SLES 11 SP3 -> SLES 11 SP4

SLES 10 SP4からのアップグレードは、ブート可能なメディア(PXEブートを含む)を介してサポートされます。詳細については、https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP4/#Update.General.Sequenceのリリースノートを参照してください。

SLEDユーザへの注意:一部の開発パッケージは、SLED11-SP2インストールメディアからSLED11-Extrasリポジトリに移動されました。アップグレード時に依存関係の競合を回避するには、実際のアップグレードを実行する前にこのリポジトリを有効化してください。yast2 repositoriesを実行し、そこでSLED11-Extrasを有効化します。SLESでは、この余分なステップは不要です。

SUSE Linux Enterprise 11 GAからのアップグレード

SUSE Linux Enterprise 11 SP3への直接的なマイグレーションパスはサポートされていません。まず、SUSE Linux Enterprise 11 GAからSP1へのアップデートを実行する必要があります。その後、7.5項 「SLE 11 SP1からSLE 11 SP2へのアップデート」および7.6項 「SLE 11 SP2からSLE 11 SP3へのアップデート」に従って手順を進めます。

SUSE Linux Enterprise 11 SP1からのアップグレード

詳細については、7.5項 「SLE 11 SP1からSLE 11 SP2へのアップデート」を参照してください。

SUSE Linux Enterprise 11 SP2からのアップグレード

詳細については、7.6項 「SLE 11 SP2からSLE 11 SP3へのアップデート」を参照してください。

SUSE Linux Enterprise 11 SP3からのアップグレード

詳細については、7.7項 「SLE 11 SP3からSLE 11 SP4へのアップデート」を参照してください。

重要
重要: クロスアーキテクチャアップグレードはサポートされない

クロスアーキテクチャアップグレード(32ビットから64ビット、64ビットから32ビットへのアップグレード)はサポートされていません。

7.4 アップデートのための一般的な準備

アップデート手順を開始する前に、システムが正しく準備されていることを確認します。準備内容には、データのバックアップとリリースノートの確認などがあります。

7.4.1 バックアップの作成

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

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

7.4.2 パーティションとディスク容量

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

例 7.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

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

7.4.3 仮想マシンのシャットダウン

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

7.4.4 バージョン固有の要件

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

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

7.5 SLE 11 SP1からSLE 11 SP2へのアップデート

SUSE Linux Enterprise 11 SP1システムからサービスパック2へのアップデートについては、さまざまな方法がサポートされています。オンラインのアップデートツールを使用してそれぞれのパッチをインストールすることでアップデートするか(オンラインマイグレーション)、サービスパックのインストールメディアを介してアップデートすることができます。さらに、Subscription Management ToolまたはSUSE Managerをホストするサーバを介して実行できます。

オンラインマイグレーションは、次のツールによってサポートされています。

  • YaST Wagon (グラフィカルユーザインタフェース)

  • zypper (コマンドライン)

または、サービスパックメディア(DVD ISOイメージ)全体をダウンロードすることもできます。アップデートプロセスは、物理的なサービスパックメディアまたはネットワークインストールソースからブートすることで開始します。

7.5.1 オンラインマイグレーション

オンラインマイグレーションによるシステムのアップデートは、稼働中のシステム内から実行されます。アップデートの完了後、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オンラインアップデートまたは6.1.3項 「Zypperによるソフトウェアの更新」を参照してください。オンラインアップデートツールの

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

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

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

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

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

SLES 11 SP1システムの場合は、https://www.suse.com/support/kb/doc.php?id=7011872で必要な手順を確認してください。次の手順は、SP2からSP3へのオンラインマイグレーションで実行します。

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

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

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

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

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

    アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、Check Automatic Repository Changesを選択します。

    次へで続行します。

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

  6. Update MethodダイアログでCheck Automatic Repository Changesを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、OKで続行します。

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

    完全マイグレーション

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

    最小マイグレーション

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

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

    選択内容を確認します。

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

    アドオン製品

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

    アップデートオプション

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

    パッケージ

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

    バックアップ

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

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

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

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

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

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

    2. SuSEconfigが実行されます。

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

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

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

7.5.1.3 zypperによるオンラインマイグレーション

  1. すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な製品/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    このコマンドでは、少なくともSUSE_SLES-SP2-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。

  2. zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。

    zypper in -t product SUSE_SLES-SP2-migration
  3. それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。

    suse_register -d 2 -L /root/.suse_register.log
  4. リポジトリとサービスを再度リフレッシュします。

    zypper ref -s
  5. zypper lrで取得可能なリポジトリのリストを確認します。少なくとも次のリポジトリを有効化する必要があります。

    • SLES11-SP1-Pool

    • SLES11-SP1-Updates

    • SLES11-SP2-Core

    • SLES11-SP2-Updates

    インストールの範囲によっては、アドオン製品や拡張機能用のリポジトリをさらに有効化する必要があります。

    これらのリポジトリのいずれかが有効でない場合(このワークフローに従うと、SP2のリポジトリはデフォルトでは有効化されません)、zypper modifyrepo --enable REPOSITORY ALIASを使用して有効化します。たとえば次のようになります。

    zypper modifyrepo --enable SLES11-SP2-Core SLES11-SP2-Updates

    セットアップにSP2と互換性がない可能性があるサードパーティのリポジトリが含まれている場合は、zypper modifyrepo --disable REPOSITORY ALIASを使用してそれらを無効にします。

  6. これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。

    zypper dup --from SLES11-SP2-Core --from SLES11-SP2-Updates

    yを入力して、アップグレードを開始します。

  7. 前のステップからの配布アップグレードが完了したら、[Minimal Migration]が実行されたことになります(パッケージの最小限のセットが最新のSP2レベルに更新されたということです)。[Full Migration]を実行しない場合は、このステップをスキップします。

    [Full Migration]を実行する(すべてのパッケージを最新のSP2レベルに更新する)には、次のコマンドを実行します。

    zypper update -t patch
  8. これでSP2へのアップグレードは完了したので、製品を再登録する必要があります。

    suse_register -d 2 -L /root/.suse_register.log
  9. 最後に、システムを再起動します。

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

7.5.2 インストールソースからブートすることでアップデート

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

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

7.5.2.1 ローカルDVDドライブからのアップデート

SUSE Linux Enterprise SPの新規インストールを開始する前に、サービスパックのインストールメディア(DVD)が全部揃っていることを確認してください。

手順 7.1: サービスパックメディアからのブート
  1. 1枚目のSUSE Linux Enterprise SPメディアを挿入し、マシンをブートします。元のSUSE Linux Enterprise 11のインストール時と同様のブート画面が表示されます。

  2. インストールを選択し、第6章 「YaSTによるインストールのYaSTインストールに関する説明に従って作業を続行してください。

7.5.2.2 ネットワークインストールソースからのアップデート

SUSE Linux Enterprise SPのネットワークインストールソースからのアップデートを開始する前に、次の要件を満たしていることを確認します。

リモートサーバからのアップグレードの詳細については、第14章 「リモートインストールを参照してください。

7.5.2.2.1 ネットワークインストール - DVDからのブート

ブートメディアとしてSPのDVDを使ってネットワークインストールを実行するには、次の手順に従います。

  1. SUSE Linux Enterprise SP DVD 1を挿入し、マシンをブートします。元のSUSE Linux Enterprise 11のインストール時と同様のブート画面が表示されます。

  2. インストールを選択してサービスパックカーネルをブートし、 F4キーを押してネットワークインストールソースの種類(FTP、HTTP、NFS、またはSMB)を選択します。

  3. 適切なパス情報を入力するか、SLPをインストールソースとして選択します。

  4. 表示されるものから適切なインストールサーバを選択するか、6.1.2項 「SLPを使用しないネットワークソースからのインストール」に説明しているとおり、ブートオプションプロンプトを使用してインストールソースの種類とその実際の場所を指定します。YaSTが起動します。

    7.5.2.3項 「アップデート手順」の説明に従って、インストールを完了します。

7.5.2.2.2 ネットワークインストール - PXEブート

ネットワークからSUSE Linux Enterpriseサービスパックのネットワークインストールを実行するには、次の手順に従います。

  1. 14.3.5項 「ターゲットシステムでPXEブートの準備をする」に従って、DHCPサーバのセットアップを調整してPXEブートに必要なアドレス情報を取得します。

  2. PXEブートに必要なブートイメージが保管されるTFTPサーバをセットアップします。

    このセットアップを実行するには、SUSE Linux EnterpriseサービスパックのCDまたはDVDの1枚目を使用するか、または14.3.2項 「TFTPサーバのセットアップ」の手順に従います。

  3. ターゲットコンピュータにPXEブートとWake-on-LANを準備します。

  4. ターゲットシステムのブートを開始し、VNCを使用してこのコンピュータで実行中のインストールルーチンにリモートで接続します。詳細については、14.5.1項 「VNCによるインストール」を参照してください。

  5. 7.5.2.3項 「アップデート手順」の説明に従って、インストールを完了します。

7.5.2.3 アップデート手順

インストールメディアまたはネットワークから正しくブートしたら、次の手順を実行してアップデートを開始します。

  1. ようこそ画面で、言語およびキーボードを選択し、ライセンス契約に同意します。次へで続行します。

  2. 物理メディアからブートした場合は、メディアチェックを実行して、メディアの整合性を確認します。すでにメディアをチェック済みの場合は、このステップをスキップします。

  3. Installation Mode画面で、アップデートを選択します。次へをクリックすると、アップデート手順が開始されます。

7.5.3 サブスクリプション管理ツール(SMT)によるアップデート

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

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

7.5.4 SUSE Managerによるアップデート

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

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

7.6 SLE 11 SP2からSLE 11 SP3へのアップデート

オンラインマイグレーションは、次のツールによってサポートされています。

  • YaST Wagon (グラフィカルユーザインタフェース)

  • zypper (コマンドライン)

オンラインマイグレーションを介してシステムをアップデートする場合、アップデートはシステムの稼働中に実行されます。アップデートの完了後、1度だけ再起動の必要があります。次に示す代替方法によってアップデートを行うこともできます。

7.6.1 要件

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

製品登録

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、Check Automatic Repository Changesを選択します。

    次へで続行します。

  5. システムが再登録されます。このプロセスの実行中に、SP3-PoolおよびSP3-Updatesチャネルがシステムに追加されます(詳細については、7.2.3項 「チャネルモデル」を参照してください)。チャネルの追加を確認します。

  6. Update MethodダイアログでCheck Automatic Repository Changesを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、OKで続行します。

  7. Distribution Upgrade Settings画面が開き、アップデート設定の概要が表示されます。次のセクションを使用できます。

    アドオン製品

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

    アップデートオプション

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

    パッケージ

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

    バックアップ

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

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

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

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

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

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

    2. SuSEconfigが実行されます。

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

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

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

7.6.3 zypperによるオンラインマイグレーション

  1. すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な製品/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    このコマンドでは、少なくともSUSE_SLES-SP3-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。

  2. zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。

    zypper in -t product SUSE_SLES-SP3-migration
  3. それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。

    suse_register -d 2 -L /root/.suse_register.log
  4. リポジトリとサービスをリフレッシュします。

    zypper ref -s
  5. zypper lrで取得可能なリポジトリのリストを確認します。

    これらのリポジトリのいずれかが有効でない場合(このワークフローに従うと、SP3のリポジトリはデフォルトでは有効化されません)、zypper modifyrepo --enable REPOSITORY ALIASを使用して有効化します。たとえば次のようになります。

    zypper modifyrepo --enable SLES11-SP3-Core SLES11-SP3-Updates

    セットアップにSP3と互換性がない可能性があるサードパーティのリポジトリが含まれている場合は、zypper modifyrepo --disable REPOSITORY ALIASを使用してそれらを無効にします。

  6. これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。

    zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates

    yを入力して、アップグレードを開始します。

  7. 前のステップからの配布アップグレードが完了したら、次のコマンドを実行します。

    zypper update -t patch
  8. これでSP3へのアップグレードは完了したので、製品を再登録する必要があります。

    suse_register -d 2 -L /root/.suse_register.log
  9. 最後に、システムを再起動します。

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

7.7 SLE 11 SP3からSLE 11 SP4へのアップデート

SUSE Linux Enterprise Server 11 SP3システムからサービスパック4へのアップデートについては、さまざまな方法がサポートされています。オンラインのアップデートツールを使用してそれぞれのパッチをインストールすることでアップデートするか(オンラインマイグレーション)、サービスパックのインストールメディアを介してアップデートすることができます。さらに、サブスクリプション管理ツール(SMT)またはSUSE Managerをホストするサーバを介して実行できます。

オンラインマイグレーションは、次のツールによってサポートされています。

  • YaST Wagon (グラフィカルユーザインタフェース)

  • zypper (コマンドライン)

または、サービスパックメディア(DVD ISOイメージ)全体をダウンロードすることもできます。アップデートプロセスは、物理的なサービスパックメディアまたはネットワークインストールソースからブートすることで開始します。

7.7.1 オンラインマイグレーション

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

7.7.1.1 要件

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

製品登録

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

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

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

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

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

オンラインアップデートツールの詳細については、セクション1.0「YaSTオンラインアップデート」(↑管理ガイド)またはセクション6.1.3「Zypperによるソフトウェアの更新」(↑管理ガイド)を参照してください。

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

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

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

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

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

SLES 11 SP1システムの場合は、https://www.suse.com/support/kb/doc.php?id=7011872で必要な手順を確認してください。次の手順は、SP3からSP4へのオンラインマイグレーションで実行します。

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

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

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

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

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

    アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、Check Automatic Repository Changesを選択します。

    次へで続行します。

  5. システムが再登録されます。このプロセスの実行中に、SP4-PoolおよびSP4-Updatesチャネルがシステムに追加されます(詳細については、7.2.3項 「チャネルモデル」を参照してください)。チャネルの追加を確認します。

  6. Update MethodダイアログでCheck Automatic Repository Changesを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、OKで続行します。

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

    完全マイグレーション

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

    最小マイグレーション

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

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

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

    アドオン製品

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

    アップデートオプション

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

    パッケージ

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

    バックアップ

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

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

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

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

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

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

    2. SuSEconfigが実行されます。

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

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

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

7.7.1.3 zypperによるオンラインマイグレーション

  1. すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な製品/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    このコマンドでは、少なくともSUSE_SLES-SP4-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。

  2. zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。

    zypper in -t product SUSE_SLES-SP4-migration
  3. それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。

    suse_register -d 2 -L /root/.suse_register.log
  4. リポジトリとサービスをリフレッシュします。

    zypper ref -s
  5. zypper lrで取得可能なリポジトリのリストを確認します。少なくとも次のリポジトリを有効化する必要があります。

    • SLES11-SP4-Pool

    • SLES11-SP4-Updates

    インストールの範囲によっては、アドオン製品や拡張機能用のリポジトリをさらに有効化する必要があります。

    これらのリポジトリのいずれかが有効でない場合(このワークフローに従うと、SP4のリポジトリはデフォルトでは有効化されません)、zypper modifyrepo --enable REPOSITORY ALIASを使用して有効化します。たとえば次のようになります。

    zypper modifyrepo --enable SLES11-SP4-Pool --enable SLES11-SP4-Updates

    セットアップにSP4と互換性がない可能性があるサードパーティのリポジトリが含まれている場合は、zypper modifyrepo --disable REPOSITORY ALIASを使用してそれらを無効にします。

  6. これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。

    zypper dup --from SLES11-SP4-Pool --from SLES11-SP4-Updates

    yを入力して、アップグレードを開始します。

  7. 前のステップからの配布アップグレードが完了したら、最小マイグレーションが実行されたことになります(パッケージの最小限のセットが最新のSP4レベルにアップデートされたということです)。完全マイグレーションを実行しない場合は、このステップをスキップします。

    [Full Migration]を実行する(すべてのパッケージを最新のSP4レベルに更新する)には、次のコマンドを実行します。

    zypper update -t patch
  8. これでSP4へのアップグレードは完了したので、製品を再登録する必要があります。

    suse_register -d 2 -L /root/.suse_register.log
  9. 最後に、システムを再起動します。

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

7.7.1.4 インストールソースからブートすることでアップデート

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

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

7.8 ソースコードのバックポート

SUSEではバックポートを広範囲に使用します。このセクションでは、ソフトウェアの機能と問題を判断するためにバージョン番号を比較しても当てにならない可能性がある理由について説明します。

7.8.1 バックポートの理由

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

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

  • バグ修正(機能を中断する限定的な可能性がある)。

  • 変更(既存の機能を中断する可能性がある)。

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

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

  • パッケージとアップストリームバージョンの変更内容の差があまりに大きくなり、バックポートが不可能になってしまった場合。

  • 本質的に経年劣化するソフトウェア(マルウェア対策ソフトウェアなど)。

7.8.2 バックポートを行う理由

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

  • SUSEのエンタープライズ製品上で使用する製品を構築する際にソフトウェアベンダーが信頼することのできる安定したインタフェース(API)を提供すること。

  • SUSEのエンタープライズ製品のリリースで使用するパッケージが、単体としてもエンタープライズ製品全体の一部としても、最高品質であり、完全にテスト済みであることを確認すること。

  • SUSEのエンタープライズ製品に対するその他のベンダーによるさまざまな証明書を維持すること(OracleまたはSAP製品の証明書など)。

  • SUSEの開発者が、リリース全体に薄く広く注意を拡散させる必要なく、できるだけ優れた次のバージョンの製品の開発に集中できるようにすること。

  • 特定のエンタープライズ向けリリースの内容の明確性を保ち、サポートがそのリリースについて正確かつタイムリーな情報を提供できるようにすること。

7.8.3 バックポートを行わない理由

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

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

7.8.4 バージョン番号の解釈に対するバックポートの意味

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

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

  • パッケージの変更ログ:

    rpm -q --changelog name-of-installed-package
    rpm -qp --changelog packagefile.rpm

    パッケージの変更履歴を簡単にドキュメント化した出力です。

  • パッケージの変更ログには、NovellのBugzillaトラッキングシステム内でバグを示すbnc#1234のようなエントリや、その他のバグトラッキングシステムへのリンクなどが含まれます(機密保護ポリシーにより、ユーザがこうした情報のすべてにアクセスできるわけではありません)。

  • パッケージには、SUSEパッケージに固有の一般的な概要情報を含む/usr/share/doc/packagename/README.SUSEまたはREADME.SuSEファイルが格納されている場合もあります。

  • RPMソースパッケージには、通常のバイナリRPMを個別のファイルとして構築するときに適用されたパッチが含まれます。これらのファイルは、ソースコードの解読に精通していれば解釈することができます。詳細については、Maximum RPMブックを参照してください。

  • セキュリティ上のバグ修正については、SUSEのセキュリティ告知を参照してください。バグは、CAN-2005-2495などの標準名で示されることがよくあります。こうした名前は、Common Vulnerabilities and Exposures (CVE)によって維持されています。

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

7.9 Atomicアップデート

Atomicアップデートは、システムの2つのコピーを管理し、更新失敗後の容易な復元を可能にするツールに基づいています。提供されたツールを使用するには、特別なディスクパーティション設定が必要です。システムの各コピーは、それ独自のプライマリパーティションに常駐します。更新が失敗した場合、常に、システムの前の状態(もう一方のパーティションで利用できる)に戻ることができます。

7.9.1 設定

警告
警告: 厳格なパーティション分割要件

実装では、ディスクパーティションに関する厳格な要件があります。つまり、最初のルートパーティションは、/dev/sda1とし、全デスクサイズの半分を超えてはなりません。次に、ツールによって、システムの2つ目のルートパーティションとして/dev/sda2が作成されます。追加パーティション(可能な場合)は、両方のブートパーティションで共有されます。したがって、追加パーティションのサイズを考慮に入れて、最初のパーティションのサイズを適宜減らしてください。大まかな計算は、次のようになります。

ディスク全体のサイズ-sda1のサイズ-sda2のサイズ = 追加パーティションの空き領域

  1. /dev/sda1が単一のルートパーティションとして全ディスクサイズの半分未満を占めるシステムをインストールします。

  2. インストールしたシステムを、必要に応じてカスタマイズします。multi-update-toolsパッケージを必ずインストールしてください。

  3. multi-update-setup --partitionを実行します。このコマンドは、同様のサイズでシステムの2つ目のルートパーティション(/dev/sda2)を作成します。

  4. 必要に応じてディスクの残りをパーティション分割し、カスタマイズ(*)を続行します。

  5. multi-update-setup --cloneを実行して、システムをもう一方のパーティションにコピーします。このコマンドで、ターゲットシステムの/etc/fstabにある/ (ルート)エントリも変更します。

  6. 必要に応じて、さらにカスタマイズ(*)します。

  7. multi-update-setup --bootloaderを実行して、ブートローダの設定を初期化します。ブートローダのメニューに、もう一方のシステムをブートするためのエントリが組み込まれます。

    警告
    警告: 必須のGRUBブートローダ

    GRUBブートローダのインストールは必須です。それらのツールは、他のブートローダと互換性がありません。

  8. (*)でマークされたカスタマイズがない場合は、multi-update-setup --completeを使用して3つのステップをすべて実行します。

7.9.2 もう一方のシステムの更新

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

7.9.3 トラブルシューティング

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

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

GRUBの詳細については、第11章 「ブートローダGRUBを参照してください。

7.9.4 制限

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

7.9.5 詳細情報

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

7.10 YaST Wagonのマイグレーションフック

マイグレーションフックによって、マイグレーションプロセスの過程のどこかの時点で、カスタムの外部スクリプトを実行できます。これらのスクリプトを使用して、通常のRPMスクリプトでは処理できない特定の問題を処理したり、マイグレーション中に必要とされるような(通常のパッケージアップデートでは必要とされない)追加のアクションを実行することができます。

マイグレーションフックはルート権限で実行されるので、スクリプト内では任意の保守タスクを実行できます(サービスの開始/停止、データのバックアップ、データマイグレーションなど)。これらのスクリプトは対話型にはできません。YaSTでの実行中にSTDINおよびSTDOUTがパイプにリダイレクトされます。Xセッションは使用できません。すべてのケースで使用できるとは限らないからです(テキストモードで実行中の場合など)。フックスクリプトについては、実行可能パーミッションを設定することを忘れないでください。

マイグレーションフックは、yast2-wagonパッケージのバージョン2.17.32.1 (SLES11-SP2に対するアップデートとして提供)または2.17.34 (SLES11-SP3に含まれる)以上でサポートされています。

7.10.1 フックスクリプトの場所と命名規則

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

step

事前定義されたマイグレーションステップ名で、現在のマイグレーションステップを説明します。

seq

00~99までのシーケンス番号で、これによりスクリプトの実行順序を設定することができます(正しくソートするためには、必ず00から開始することが重要です)。

prefix

競合を避けるために一意にする必要があります(ネームスペースのように)。(パッケージの一部であれば)パッケージ名、またはベンダ名やインターネットドメイン名などを使用します。一意であると十分に考えられるものであれば基本的に何でも使用できます。

name

任意の文字列にできます(スクリプトを区別するだけのものです)。わかりやすい名前にすることをお勧めします。

例 7.2: 完全パスのフックスクリプト
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

7.10.2 フックスクリプトの終了値

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

7.10.3 等羃のスクリプト

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

7.10.4 サポートされているフックのリスト

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

before_init

最初に開始されます(注意: Wagonの再起動後にもう一度呼び出されます)。

before_welcome , after_welcome

[ようこそ]ダイアログが表示される前後に開始されます。

before_registration_check , after_registration_check

Wagonが登録状態をチェックします(一部の製品の登録の期限が切れていると、マイグレーションに失敗する場合があります)。すべてがOKの場合は何もダイアログが表示されず、Wagonによって自動的に次のステップに進みます。

before_custom_url , after_custom_url

リポジトリマネージャが開始されます(オプション、パッチCDモードのみ)。

before_self_update , after_self_update

Wagonのアップデートそのものの前後に呼び出されます(最新バージョンがマイグレーションに使用されていることを確認します)。

before_installing_migration_products , after_installing_migration_products

マイグレーション製品のインストールの前後に呼び出されます。

before_selecting_migration_source , after_selecting_migration_source

Novell Customer Centerリポジトリ経由でマイグレートするのか、カスタムリポジトリを使用してマイグレートするのか、Wagonがユーザに尋ねます。次のステップはこのユーザ選択によって決まります。

before_registration , after_registration

SUSEレジスタが実行されます(マイグレーションリポジトリを追加するため)。

before_repo_selection , after_repo_selection

手動のリポジトリ管理。

before_set_migration_repo , after_set_migration_repo

マイグレーションリポジトリ(Novell Customer Centerの使用時は完全/最小マイグレーション)を選択するか、リポジトリ選択を更新します(カスタムリポジトリマイグレーション)。

before_package_migration

パッケージのアップデートが開始される前、このステップの後に実際のマイグレーションが開始され、前の状態に自動的に戻ることはできなくなります(このフェーズで中止すると、システムに矛盾が発生し(半分アップグレードされた状態)、手動のロールバックが必要になります)。

before_registration , after_registration

SUSEレジスタが実行されます(アップデートされた製品を登録するため)。

before_congratulate , after_congratulate

マイグレーションが成功した結果、Wagonによって成功を示すダイアログが表示される前後。

before_exit

Wagonが終了する直前に呼び出されます(中止後や再起動時も含め、マイグレーションの結果に関係なく常に呼び出されます)。

7.10.5 中止のフック

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

before_abort

ユーザがマイグレーションの中止を確定しました。

before_abort_rollback , after_abort_rollback

ユーザが中止後にロールバックを確定しました(マイグレーション開始前にインストールされていた古い製品に戻ります)。これらのフックはbefore_abortの後に呼び出され、ユーザがロールバックを確定しない場合はスキップされます。

7.10.6 再起動のフック

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

before_restart

Wagonは終了し、もう一度開始されます。

after_restart

Wagonは再起動されており、マイグレーションワークフローの次のステップが実行されます。

7.10.7 通常使用するフック

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

  • システムをマイグレートする前(まだ前のバージョンを実行しているとき)に何らかのアクションを実行するには、before_package_migrationフックを使用します。

    この時点では、マイグレーションの準備ができていて開始寸前であることは明確ですが、それ以前のすべてのステップで、マイグレーションを中止することが可能でした。

  • システムのマイグレート後(システムはマイグレード後の新しいバージョンを実行しているが、何かまだアクティブになっていない機能があるとき(カーネルのアップデート後にリブートが必要だったり、サービスのアップデート後に再起動が必要な場合など))に何らかのアクションを実行するには、before_congratulateまたはafter_congratulateフックを使用します。

    これは、before_package_migrationフックによる一時的な結果を消去する場合にも使用できます。この時点で、マイグレーションは正常に終了しています。

  • マイグレーションが中止された場合に変更を元に戻すには、事例に応じて、中止のフックのいずれかを使用します。中止のフックはいつでも呼び出すことができるので、元に戻す必要はないかもしれません(変更を実行するフックがまだ呼び出されていない可能性があります)。中止のフックでは、現在の状態をチェックする必要があります。

7.10.8 廃止されたフック

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

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

このページを印刷