目次
概要
SUSE® Linux Enterprise (SLE)には、完全な再インストールを実行せずに既存のシステムを新しいバージョンに更新できるオプションがあります。新たにインストールする必要はありません。ホームディレクトリ、システム設定などの既存のデータは、そのまま保持されます。製品のライフサイクル中は、サービスパックを適用することで、システムセキュリティを向上させ、ソフトウェアの不具合を修正し、新機能にアクセスすることができます。CD/DVDドライブから、またはネットワーク上のインストールソースからインストールします。
この章では、いくつかの用語を使用します。それらの情報を理解するには、以下の定義をお読みください。
バックポートとは、新しいバージョンのソフトウェアによる特定の変更内容を採用し、それを古いバージョンに適用することを意味します。最も一般的な使用事例は、古いソフトウェアコンポーネントのセキュリティホールの修正です。通常は、拡張機能や(頻度は低いものの)新機能を提供するための保守モデルの一部にもなります。
delatrpmは、2つの定義されたパッケージバージョンのバイナリ差分のみで構成されているので、ダウンロードサイズは最小です。インストールの前に、RPMのフルパッケージがローカルコンピュータ上で再構築されます。
オープンソースワールドにおけるソフトウェア開発方法のメタファーです(アップストリームと対比)。「ダウンストリーム」という用語は、アップストリームからのソースコードを他のソフトウェアと統合し、エンドユーザが使用するためのディストリビューションを構築する、SUSEのような人や組織を指しています。つまり、ソフトウェアは開発者からインテグレータを介して、エンドユーザーまで、ダウンストリーム(下向き)に流れていきます。
それぞれのパッチをインストールするために、(インストールメディアではなく)オンラインアップデートツールを使用して、サービスパック(SP)への更新を行うことです。インストールシステムのすべてのパッケージを最新状態にアップデートします(SP3およびSP2アップデートを含む)。
パッケージは、rpm形式で圧縮されたファイルで、特定のプログラムのすべてのファイルが格納されています。環境設定、サンプル、ドキュメントなどのオプションコンポーネントも含まれます。
パッチは、1つ以上のパッケージから成り、deltarpmで適用されることがあります。また、まだインストールされていないパッケージへの依存関係を導入することもあります。
複数のパッチを組み合わせて、インストールまたは展開しやすい形式にします。サービスパックには番号が付けられ、通常、プログラムのセキュリティ修正、更新、アップグレード、または拡張機能が含まれます。
オープンソースワールドにおけるソフトウェア開発方法のメタファーです(ダウンストリームと対比)。アップストリームという用語は、ソースコードとして配布されるソフトウェアの元のプロジェクト、作者、またはメンテナンス者を指しています。フィードバック、パッチ、拡張機能、その他の改良機能は、エンドユーザまたはコントリビュータからアップストリーム(上流)の開発者に流れていきます。開発者は、リクエストを組み込むのか却下するのか決定します。
プロジェクトメンバーがリクエストを組み込むように決定すると、それが新しいバージョンのソフトウェアに出現します。受け入れられたリクエストは、すべての関係者にメリットをもたらします。
リクエストが受け入れられない場合は、別の理由が考えられます。プロジェクトのガイドラインに準拠していない、無効である、すでに組み込まれている、プロジェクトに関係ないかロードマップ上に存在しないなどの中のいずれかの理由です。リクエストが受け入れられない場合、アップストリームの開発者にとっては、自分のパッチをアップストリームのコードと同期させる必要があるために困難が生じます。この操作は一般的には回避されますが、まだ必要な場合もあります。
パッケージの新しいマイナーバージョンのインストール。
パッケージまたは配布の新しい主要バージョンのインストール。これにより新機能がもたらされます。
SUSE Linux Enterprise 11の保守モデルでは、サービスパックの柔軟性と制御を組み合わせています。このモデルには、次の利点があります。
サービスパックが軽量化し、そのテストと展開が容易になります。
旧バージョンとの共存を可能にする一方で、フルシステムをサポートします。
選択的な機能拡張でサービスパック間のマーケットニーズに対処し、一般更新リポジトリ内におけるより多くの更新を可能にします。機能拡張の選択により、サービスパックの間隔が長期化するのを緩和します。
この数年間、お客様のフィードバックに基づく機能改善の必要性が明らかになり、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により、以下で構成される新しいリポジトリモデルが導入されました。
SLES 11 SP1アップデートリポジトリは、購読されたままです。SP2にも適用可能なすべてのアップデートは、SP1アップデートリポジトリにもリリースされるか、SP1アップデートリポジトリのみにリリースされています。つまり、ここには、ABIおよびAPIの互換性を保持しているすべてのアップデートが引き続き配信されています。
SLES 11 SP2アップデートリポジトリには、(さまざまな理由で)SP1アップデートリポジトリには配信できない最新の革新的なアップデートのみが含まれています。これに加えて当社ではコアリポジトリを導入しました。これは、SP1とSP2のどちらのアップデートリポジトリにもリリースされなかったパッケージの「ギャップ」を提供するものです。
SLES 11 SP4は、SLES 10と同様のチャネルモデルを持つことになります。このモデルは、特定のサービスパックを対象にしたアップデートを提供するための最も簡単で迅速な方法として受け入れられています。すべてのアップデートは、特別なアップデートチャネルを介して提供されます。お使いのマシンでは追加のチャネルが使用可能になりますが、古いチャネルは削除されます。
上記の一部の側面は、図7.1「メンテナンス配信の進化(SLEDにも当てはまる)」で説明されています。
弊社の製品のライフサイクルは10年です。そのうち10年間は一般サポート、3年間は拡張サポートが適用されます。主要リリースは4年ごと、サービスパックは18カ月ごとに作成されます。Long Term Service Pack Support(長期サービスパックサポート)は、延長された期間つまり延長された主要リリースライフサイクルをサポートします(図7.2「長期サービスパックサポート」参照)。
Long Term Service Pack Supportには、アクティブな購読(標準または優先のいずれか)が必要です。このサポートは、L1やL2の購読約款には影響しません。セキュリティ更新は、「プロアクティブに」処理されます。これらは、非ユーザ主導の更新であり、重大な脆弱性やカーネルでのローカルルートエクスプロイトなどのルートエクスプロイトの修正をユーザ介入なしで直接実行します。
拡張サポートレベルの範囲は、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エンジニアリングサポート |
✓ |
✓ |
✓ |
✓ |
✓ |
|
バックポートあり |
✓ |
✓ |
✓ |
✓ | |
以前の保守モデルでは、SUSE Linux Enterprise Serverには、SLES11-SPx-PoolとSLES11-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
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
オプションチャネル |
SP1
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
製品固有(例) |
|
|
必要なチャネルの説明
パックされていないインストールメディアのサブセットで、SPxの「コア」だと見なされるパッケージのみが格納されます(パッケージ全体の約30%)。SPリポジトリには、SPとそのテーマ(ハードウェアイネーブルメントなど)に固有のパッケージのみが格納されます。SP2のみに存在します。
保守によって更新されるのは、対応するCoreまたはPoolリポジトリ内のパッケージのみです。
インストールメディアからのすべてのバイナリRPMとパターン情報が格納され、ステータスメタデータをサポートします。
オプションチャネルの説明
これらのチャネルには、静的なコンテンツが格納されます。ただし、アップデートを受信するのはDebuginfo-Updatesチャネルのみです。問題の発生時にデバッグ情報を含むライブラリをインストールする必要がある場合は、これらのチャネルを有効にします。
未使用です。(将来的な)アドオン製品用のパッケージを格納するためにサポートされています。SLES 11 SP4以降、Extension Storeチャネルは削除されます。
Long Term Support Service (LTSS)を含むインストールの場合に、対応するPoolリポジトリ内のパッケージが保守によって更新されます。この特定のチャネルにはLTSS契約が必要です。
SUSE Linux Enterprise 11 SP3/SP4. SP3のインストールでは、SLES11-SP3-PoolとSLES11-SP3-Updatesという2つのチャネルのみが使用可能です。SP2からの以前のチャネルは表示されますが、有効にはなりません。これらの無効なチャネルは、特定のニーズを持つユーザのみが必要としています。
登録を行うと、システムが 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
これらのバージョンからの直接的なアップグレードパスはサポートされていません。その代わりに、新しいインストールの実行を推奨します。
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 SP3への直接的なマイグレーションパスはサポートされていません。まず、SUSE Linux Enterprise 11 GAからSP1へのアップデートを実行する必要があります。その後、7.5項 「SLE 11 SP1からSLE 11 SP2へのアップデート」および7.6項 「SLE 11 SP2からSLE 11 SP3へのアップデート」に従って手順を進めます。
詳細については、7.5項 「SLE 11 SP1からSLE 11 SP2へのアップデート」を参照してください。
詳細については、7.6項 「SLE 11 SP2からSLE 11 SP3へのアップデート」を参照してください。
詳細については、7.7項 「SLE 11 SP3からSLE 11 SP4へのアップデート」を参照してください。
![]() | クロスアーキテクチャアップグレードはサポートされない |
|---|---|
クロスアーキテクチャアップグレード(32ビットから64ビット、64ビットから32ビットへのアップグレード)はサポートされていません。 | |
アップデート手順を開始する前に、システムが正しく準備されていることを確認します。準備内容には、データのバックアップとリリースノートの確認などがあります。
更新の前に、既存の設定ファイルを別個のメディア(テープデバイス、リムーバブルハードディスクなど)にコピーして、データをバックアップします。主に、/etcの下に格納されているファイル、また、/varと/optの下にあるディレクトリとファイルの一部に当てはまります。さらに、/home (HOMEディレクトリ)下のユーザデータをバックアップメディアに書き込むようにします。このデータは、rootユーザでバックアップします。rootのみに、すべてのローカルファイルに関する読み込みパーミッションがあります。
YaSTのインストールモードとしてを選択している場合は、もっと後の時点で(システム)バックアップを実行することができます。変更されたすべてのファイルと/etc/sysconfigディレクトリにあるファイルを含めることができます。ただし、これは完全なバックアップではありません。前述したその他の重要なディレクトリがすべて含まれていないからです。/var/adm/backupディレクトリでバックアップを見つけます。
更新を開始する前に、ルートパーティションの記録をとります。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コマンドで、利用できるパーティションの容量を調べてください。ディスク容量が不足していると思われる場合は、システムの更新とパーティション再設定を行う前に、データをバックアップしておきます。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。
お使いのマシンがKVMまたはXenのVMホストサーバとして機能している場合、アップデートの前には、実行中のすべてのVMゲストを正しくシャットダウンするようにします。そうでないと、更新後にゲストにアクセスできなくなる可能性があります。
バージョン固有の要件については、アップデート製品に付属しているリリースノートを参照してください。リリースノートには、アップグレード手順に関する追加情報が含まれています。
SUSE Linux Enterprise Serverの最新情報を含むリリースノートの最新バージョンのドキュメントは、http://www.suse.com/doc/sles11/#additionalでオンラインで読むことができます。
SUSE Linux Enterprise 11 SP1システムからサービスパック2へのアップデートについては、さまざまな方法がサポートされています。オンラインのアップデートツールを使用してそれぞれのパッチをインストールすることでアップデートするか(「オンラインマイグレーション」)、サービスパックのインストールメディアを介してアップデートすることができます。さらに、Subscription Management ToolまたはSUSE Managerをホストするサーバを介して実行できます。
オンラインマイグレーションは、次のツールによってサポートされています。
(グラフィカルユーザインタフェース)
zypper (コマンドライン)
または、サービスパックメディア(DVD ISOイメージ)全体をダウンロードすることもできます。アップデートプロセスは、物理的なサービスパックメディアまたはネットワークインストールソースからブートすることで開始します。
オンラインマイグレーションによるシステムのアップデートは、稼働中のシステム内から実行されます。アップデートの完了後、1度だけ再起動の必要があります。
オンラインアップデートを実行するには、次の要件を満たす必要があります。必ず、7.4項 「アップデートのための一般的な準備」も読んでください。
アップデートチャネルに接続できるようになるには、製品を登録する必要があります。そうでない場合は、YaSTのモジュール、またはsuse_registerコマンドラインツールを実行して、登録を開始します。
現在インストールされているバージョンに最新のパッチがインストールされていることを確認します。オンラインマイグレーションの前に、オンラインアップデートを実行します。グラフィカルインタフェースを使用して、YaSTオンラインアップデートまたはアップデータアプレットを起動します。コマンドラインで、次のコマンドを実行します(最後のコマンドは2回実行する必要があります)。
zypper ref -s zypper update -t patch zypper update -t patch
必要に応じて、システムを再起動します。
詳細については、第1章 YaSTオンラインアップデート (↑管理ガイド)または項 「Zypperによるソフトウェアの更新」 (第6章 コマンドラインツールによるソフトウェアの管理, ↑管理ガイド)を参照してください。オンラインアップデートツールの
セットアップにサードパーティのソフトウェアまたはアドオンソフトウェアが含まれている場合は、別のコンピュータでこのプロシージャをテストして、依存関係が更新によって破損していないかどうか確認してください。
![]() | 完全なオンラインマイグレーションを常に実行 |
|---|---|
オンラインマイグレーションは常に、最初から最後まで完全に実行する必要があります。オンラインマイグレーションが中断された場合、システムは破損され回復不能な状態になります。 | |
SLES 11 SP1システムの場合は、https://www.suse.com/support/kb/doc.php?id=7011872で必要な手順を確認してください。次の手順は、SP2からSP3へのオンラインマイグレーションで実行します。
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、トレイのアップデートアプレットには、配布アップグレードが使用可能であることを示すメッセージが表示されます。これをクリックして、YaST を起動します。または、コマンドラインからrootとして/usr/sbin/wagonを実行します。
ダイアログのを選択して確定します。
では、要件が満たされていない(必要な保守アップデートが使用可能なのに、まだインストールされていない)ことが見つかったら、自動的なセルフアップデートが実行されます。この場合再起動が必要になります。画面の指示に従って操作します。
次のダイアログで、アップデート方法を選択します。デフォルトの設定を使用するには、を選択します(推奨)。
オンラインマイグレーションに使用するソフトウェアチャネルを手動で選択するには、をクリックします。チャネルのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。SP2アップデートソースを追加します。これは、SP2インストールメディアか、SP2-CoreおよびSP2-Updatesチャネルのいずれかの可能性があります。をクリックして、ダイアログに戻ります。
アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、を選択します。
で続行します。
システムが再登録されます。このプロセスの実行中に、SP2-CoreおよびSP2-Updatesチャネルがシステムに追加されます(詳細については、7.2.3項 「チャネルモデル」を参照してください)。チャネルの追加を確認します。
ダイアログでを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、で続行します。
マイグレーションタイプを選択します。
すべてのパッケージを最新のSP2レベルに更新します。
パッケージの最小限のセットを最新のSP2レベルに更新します。
をクリックして、アップグレードに使用するリポジトリを手動で選択します。
選択内容を確認します。
画面が開き、アップデート設定の概要が表示されます。次のセクションを使用できます。
ここでは、SUSE Linux Enterprise Serverのアドオン製品か、サードパーティの製品を追加できます。
アップデート中に実行されるアクションがリストされます。インストールの前にすべてのパッケージをダウンロードするのか(デフォルト、推奨)、パッケージを1つずつダウンロードしてインストールするのかを選択できます。
アップデートの統計概要。
バックアップオプションを設定します。
およびをクリックして続行します。
![]() | オンラインマイグレーションを中止する |
|---|---|
この画面でをクリックする前と、それ以前のすべての画面では、オンラインマイグレーションを安全に中止することができます。をクリックしてアップデート手順を中止し、YaST Wagonを開始する前の状態にシステムを戻します。画面の指示に従って、Wagonを中止する前に再登録を実行し、SP2チャネルをシステムから削除します。 | |
アップデート手順の過程では、次のステップが実行されます。
パッケージが更新されます。
SuSEconfigが実行されます。
システムが再起動されます(を選択します)。
新しく更新されたシステムが再登録されます。
システムがサービスパック2に正しく更新されます。
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な「製品」が/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。
zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2
このコマンドでは、少なくともSUSE_SLES-SP2-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。
zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。
zypper in -t product SUSE_SLES-SP2-migration
それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。
suse_register -d 2 -L /root/.suse_register.log
リポジトリとサービスを再度リフレッシュします。
zypper ref -s
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を使用してそれらを無効にします。
これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。
zypper dup --from SLES11-SP2-Core --from SLES11-SP2-Updates
を入力して、アップグレードを開始します。
前のステップからの配布アップグレードが完了したら、[Minimal Migration]が実行されたことになります(パッケージの最小限のセットが最新のSP2レベルに更新されたということです)。[Full Migration]を実行しない場合は、このステップをスキップします。
[Full Migration]を実行する(すべてのパッケージを最新のSP2レベルに更新する)には、次のコマンドを実行します。
zypper update -t patch
これでSP2へのアップグレードは完了したので、製品を再登録する必要があります。
suse_register -d 2 -L /root/.suse_register.log
最後に、システムを再起動します。
システムがサービスパック2に正しく更新されます。
オンラインマイグレーション(詳細については7.5.1項 「オンラインマイグレーション」を参照)の代わりとして、インストールソース(DVDまたはネットワークインストールソース)からブートすることでシステムをアップデートできます。アップデートは、通常のインストールと同じように開始されます。
サービスパック2 ISOイメージは、http://download.novell.com/から取得できます。これをDVDに書き込むか、14.2項 「インストールソースを保持するサーバのセットアップ」の説明に従ってネットワークインストールソースを準備します。
SUSE Linux Enterprise SPの新規インストールを開始する前に、サービスパックのインストールメディア(DVD)が全部揃っていることを確認してください。
手順7.1 サービスパックメディアからのブート¶
1枚目のSUSE Linux Enterprise SPメディアを挿入し、マシンをブートします。元のSUSE Linux Enterprise 11のインストール時と同様のブート画面が表示されます。
を選択し、第6章 YaSTによるインストールのYaSTインストールに関する説明に従って作業を続行してください。
SUSE Linux Enterprise SPのネットワークインストールソースからのアップデートを開始する前に、次の要件を満たしていることを確認します。
ネットワークインストールソースが14.2項 「インストールソースを保持するサーバのセットアップ」の記述どおりにセットアップされていること。
インストールサーバと、ネームサービス、DHCP (オプションですが、PXEブートには必要)、およびOpenSLP (オプション)が含まれているターゲットコンピュータの両方で機能しているネットワーク接続が存在すること。
ターゲットシステムのブート用のSUSE Linux EnterpriseサービスパックのDVD 1か、14.3.5項 「ターゲットシステムでPXEブートの準備をする」の説明に従ってPXEブート用にセットアップされたターゲットシステムが存在すること。
リモートサーバからのアップグレードの詳細については、第14章 リモートインストールを参照してください。
ブートメディアとしてSPのDVDを使ってネットワークインストールを実行するには、次の手順に従います。
SUSE Linux Enterprise SP DVD 1を挿入し、マシンをブートします。元のSUSE Linux Enterprise 11のインストール時と同様のブート画面が表示されます。
を選択してサービスパックカーネルをブートし、 F4キーを押してネットワークインストールソースの種類(FTP、HTTP、NFS、またはSMB)を選択します。
適切なパス情報を入力するか、をインストールソースとして選択します。
表示されるものから適切なインストールサーバを選択するか、6.1.2項 「SLPを使用しないネットワークソースからのインストール」に説明しているとおり、ブートオプションプロンプトを使用してインストールソースの種類とその実際の場所を指定します。YaSTが起動します。
7.5.2.3項 「アップデート手順」の説明に従って、インストールを完了します。
ネットワークからSUSE Linux Enterpriseサービスパックのネットワークインストールを実行するには、次の手順に従います。
14.3.5項 「ターゲットシステムでPXEブートの準備をする」に従って、DHCPサーバのセットアップを調整してPXEブートに必要なアドレス情報を取得します。
PXEブートに必要なブートイメージが保管されるTFTPサーバをセットアップします。
このセットアップを実行するには、SUSE Linux EnterpriseサービスパックのCDまたはDVDの1枚目を使用するか、または14.3.2項 「TFTPサーバのセットアップ」の手順に従います。
ターゲットコンピュータにPXEブートとWake-on-LANを準備します。
ターゲットシステムのブートを開始し、VNCを使用してこのコンピュータで実行中のインストールルーチンにリモートで接続します。詳細については、14.5.1項 「VNCによるインストール」を参照してください。
7.5.2.3項 「アップデート手順」の説明に従って、インストールを完了します。
インストールメディアまたはネットワークから正しくブートしたら、次の手順を実行してアップデートを開始します。
画面で、およびを選択し、ライセンス契約に同意します。で続行します。
物理メディアからブートした場合は、を実行して、メディアの整合性を確認します。すでにメディアをチェック済みの場合は、このステップをスキップします。
画面で、を選択します。をクリックすると、アップデート手順が開始されます。
Novellアップデートサーバからクライアントシステムごとにアップデートをダウンロードする代わりに、SUSE Linux Enterprise用のサブスクリプション管理ツール(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のマニュアルに、機能の概要とサーバおよびクライアントのセットアップ方法の説明が記載されています。
オンラインマイグレーションは、次のツールによってサポートされています。
(グラフィカルユーザインタフェース)
zypper (コマンドライン)
オンラインマイグレーションを介してシステムをアップデートする場合、アップデートはシステムの稼働中に実行されます。アップデートの完了後、1度だけ再起動の必要があります。次に示す代替方法によってアップデートを行うこともできます。
オンラインアップデートを実行するには、次の要件を満たす必要があります。必ず、7.4項 「アップデートのための一般的な準備」も読んでください。
アップデートチャネルに接続できるようになるには、製品を登録する必要があります。そうでない場合は、YaSTのモジュール、またはsuse_registerコマンドラインツールを実行して、登録を開始します。
現在インストールされているバージョンに最新のパッチがインストールされていることを確認します。オンラインマイグレーションの前に、オンラインアップデートを実行します。グラフィカルインタフェースを使用して、YaSTオンラインアップデートまたはアップデータアプレットを起動します。コマンドラインで、次のコマンドを実行します(最後のコマンドは2回実行する必要があります)。
zypper ref -s zypper update -t patch zypper update -t patch
必要に応じて、システムを再起動します。
オンラインアップデートツールの詳細については、第1章 YaSTオンラインアップデート (↑管理ガイド)または項 「Zypperによるソフトウェアの更新」 (第6章 コマンドラインツールによるソフトウェアの管理, ↑管理ガイド)を参照してください。
セットアップにサードパーティのソフトウェアまたはアドオンソフトウェアが含まれている場合は、別のコンピュータでこのプロシージャをテストして、依存関係が更新によって破損していないかどうか確認してください。
![]() | 完全なオンラインマイグレーションを常に実行 |
|---|---|
オンラインマイグレーションは常に、最初から最後まで完全に実行する必要があります。オンラインマイグレーションが中断された場合、システムは破損され回復不能な状態になります。 | |
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、トレイのアップデートアプレットには、配布アップグレードが使用可能であることを示すメッセージが表示されます。これをクリックして、YaST を起動します。または、コマンドラインからrootとして/usr/sbin/wagonを実行します。
ダイアログのを選択して確定します。
では、要件が満たされていない(必要な保守アップデートが使用可能なのに、まだインストールされていない)ことが見つかったら、自動的なセルフアップデートが実行されます。この場合再起動が必要になります。画面の指示に従って操作します。
次のダイアログで、アップデート方法を選択します。デフォルトの設定を使用するには、を選択します(推奨)。
オンラインマイグレーションに使用するソフトウェアチャネルを手動で選択するには、をクリックします。チャネルのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。SP3アップデートソースを追加します。これは、SP3インストールメディアか、SP3-PoolおよびSP3-Updatesチャネルのいずれかの可能性があります。をクリックして、ダイアログに戻ります。
アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、を選択します。
で続行します。
システムが再登録されます。このプロセスの実行中に、SP3-PoolおよびSP3-Updatesチャネルがシステムに追加されます(詳細については、7.2.3項 「チャネルモデル」を参照してください)。チャネルの追加を確認します。
ダイアログでを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、で続行します。
画面が開き、アップデート設定の概要が表示されます。次のセクションを使用できます。
ここでは、SUSE Linux Enterprise Serverのアドオン製品か、サードパーティの製品を追加できます。
アップデート中に実行されるアクションがリストされます。インストールの前にすべてのパッケージをダウンロードするのか(デフォルト、推奨)、パッケージを1つずつダウンロードしてインストールするのかを選択できます。
アップデートの統計概要。
バックアップオプションを設定します。
およびをクリックして続行します。
![]() | オンラインマイグレーションを中止する |
|---|---|
この画面でをクリックする前と、それ以前のすべての画面では、オンラインマイグレーションを安全に中止することができます。をクリックしてアップデート手順を中止し、YaST Wagonを開始する前の状態にシステムを戻します。画面の指示に従って、Wagonを中止する前に再登録を実行し、SP2チャネルをシステムから削除します。 | |
アップデート手順の過程では、次のステップが実行されます。
パッケージが更新されます。
SuSEconfigが実行されます。
システムが再起動されます(を選択します)。
新しく更新されたシステムが再登録されます。
システムがサービスパック3に正しく更新されます。
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な「製品」が/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。
zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2
このコマンドでは、少なくともSUSE_SLES-SP3-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。
zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。
zypper in -t product SUSE_SLES-SP3-migration
それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。
suse_register -d 2 -L /root/.suse_register.log
リポジトリとサービスをリフレッシュします。
zypper ref -s
zypper lrで取得可能なリポジトリのリストを確認します。
これらのリポジトリのいずれかが有効でない場合(このワークフローに従うと、SP3のリポジトリはデフォルトでは有効化されません)、zypper modifyrepo --enable REPOSITORY ALIASを使用して有効化します。たとえば次のようになります。
zypper modifyrepo --enable SLES11-SP3-Core SLES11-SP3-Updates
セットアップにSP3と互換性がない可能性があるサードパーティのリポジトリが含まれている場合は、zypper modifyrepo --disable REPOSITORY ALIASを使用してそれらを無効にします。
これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。
zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates
を入力して、アップグレードを開始します。
前のステップからの配布アップグレードが完了したら、次のコマンドを実行します。
zypper update -t patch
これでSP3へのアップグレードは完了したので、製品を再登録する必要があります。
suse_register -d 2 -L /root/.suse_register.log
最後に、システムを再起動します。
システムがサービスパック3に正しく更新されます。
SUSE Linux Enterprise Server 11 SP3システムからサービスパック4へのアップデートについては、さまざまな方法がサポートされています。オンラインのアップデートツールを使用してそれぞれのパッチをインストールすることでアップデートするか(オンラインマイグレーション)、サービスパックのインストールメディアを介してアップデートすることができます。さらに、サブスクリプション管理ツール(SMT)またはSUSE Managerをホストするサーバを介して実行できます。
オンラインマイグレーションは、次のツールによってサポートされています。
YaST Wagon (グラフィカルユーザインタフェース)
zypper (コマンドライン)
または、サービスパックメディア(DVD ISOイメージ)全体をダウンロードすることもできます。アップデートプロセスは、物理的なサービスパックメディアまたはネットワークインストールソースからブートすることで開始します。
オンラインマイグレーションによるシステムのアップデートは、稼働中のシステム内から実行されます。アップデートの完了後、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によるソフトウェアの更新」(↑管理ガイド)を参照してください。
セットアップにサードパーティのソフトウェアまたはアドオンソフトウェアが含まれている場合は、別のコンピュータでこのプロシージャをテストして、依存関係が更新によって破損していないかどうか確認してください。
![]() | 完全なオンラインマイグレーションを常に実行 |
|---|---|
オンラインマイグレーションは常に、最初から最後まで完全に実行する必要があります。オンラインマイグレーションが中断された場合、システムは破損され回復不能な状態になります。 | |
SLES 11 SP1システムの場合は、https://www.suse.com/support/kb/doc.php?id=7011872で必要な手順を確認してください。次の手順は、SP3からSP4へのオンラインマイグレーションで実行します。
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、トレイのアップデートアプレットには、配布アップグレードが使用可能であることを示すメッセージが表示されます。これをクリックして、YaST を起動します。または、コマンドラインからrootとして/usr/sbin/wagonを実行します。
ダイアログのを選択して確定します。
では、要件が満たされていない(必要な保守アップデートが使用可能なのに、まだインストールされていない)ことが見つかったら、自動的なセルフアップデートが実行されます。この場合再起動が必要になります。画面の指示に従って操作します。
次のダイアログで、アップデート方法を選択します。デフォルトの設定を使用するには、を選択します(推奨)。
オンラインマイグレーションに使用するソフトウェアチャネルを手動で選択するには、をクリックします。チャネルのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。SP4アップデートソースを追加します。これは、SP4インストールメディアか、SP4-PoolおよびSP4-Updatesチャネルのいずれかの可能性があります。をクリックして、ダイアログに戻ります。
アップデートプロセスによって発生したチャネル設定に対する変更を確認する必要がある場合は、を選択します。
で続行します。
システムが再登録されます。このプロセスの実行中に、SP4-PoolおよびSP4-Updatesチャネルがシステムに追加されます(詳細については、7.2.3項 「チャネルモデル」を参照してください)。チャネルの追加を確認します。
ダイアログでを選択した場合、リポジトリのリストが表示され、チャネルを手動で有効化、無効化、追加、または削除できるようになります。終了したら、で続行します。
マイグレーションタイプを選択します。
すべてのパッケージを最新のSP4レベルに更新します。
パッケージの最小限のセットを最新のSP4レベルに更新します。
をクリックして、アップグレードに使用するリポジトリを手動で選択します。選択内容を確認します。
画面が開き、アップデート設定の概要が表示されます。次のセクションを使用できます。
ここでは、SUSE Linux Enterprise Serverのアドオン製品か、サードパーティの製品を追加できます。
アップデート中に実行されるアクションがリストされます。インストールの前にすべてのパッケージをダウンロードするのか(デフォルト、推奨)、パッケージを1つずつダウンロードしてインストールするのかを選択できます。
アップデートの統計概要。
バックアップオプションを設定します。
およびをクリックして続行します。
![]() | オンラインマイグレーションを中止する |
|---|---|
この画面でをクリックする前と、それ以前のすべての画面では、オンラインマイグレーションを安全に中止することができます。をクリックしてアップデート手順を中止し、YaST Wagonを開始する前の状態にシステムを戻します。画面の指示に従って、Wagonを中止する前に再登録を実行し、SP4チャネルをシステムから削除します。 | |
アップデート手順の過程では、次のステップが実行されます。
パッケージが更新されます。
SuSEconfigが実行されます。
システムが再起動されます(を選択します)。
新しく更新されたシステムが再登録されます。
システムがサービスパック4に正しく更新されます。
すべての要件が満たされている場合(7.5.1.1項 「要件」を参照)、オンラインマイグレーションに必要な「製品」が/etc/products.dに追加されます。次のコマンドを実行することで、これらの製品のリストを取得します。
zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2
このコマンドでは、少なくともSUSE_SLES-SP4-migrationが返されます。インストールの範囲によっては、もっと多くの製品がリストされている場合があります。
zypper in -t product LIST_OF_PRODUCTSというコマンドを使用して、前のステップで取得したマイグレーション製品をインストールします。たとえば次のようになります。
zypper in -t product SUSE_SLES-SP4-migration
それぞれのアップデートチャネルを取得するために、前のステップでインストールした製品を登録します。
suse_register -d 2 -L /root/.suse_register.log
リポジトリとサービスをリフレッシュします。
zypper ref -s
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を使用してそれらを無効にします。
これで、zypper dup --from REPO 1 --from REPO 2 ...を使用して配布アップグレードを実行するための準備がすべて整いました。 必ず--fromを使用して必要なリポジトリをすべてリストするようにしてください。たとえば次のようになります。
zypper dup --from SLES11-SP4-Pool --from SLES11-SP4-Updates
を入力して、アップグレードを開始します。
前のステップからの配布アップグレードが完了したら、最小マイグレーションが実行されたことになります(パッケージの最小限のセットが最新のSP4レベルにアップデートされたということです)。完全マイグレーションを実行しない場合は、このステップをスキップします。
[Full Migration]を実行する(すべてのパッケージを最新のSP4レベルに更新する)には、次のコマンドを実行します。
zypper update -t patch
これでSP4へのアップグレードは完了したので、製品を再登録する必要があります。
suse_register -d 2 -L /root/.suse_register.log
最後に、システムを再起動します。
システムがサービスパック4に正しく更新されます。
オンラインマイグレーションの代わりとして、インストールソース(DVDまたはネットワークインストールソース)からブートすることでシステムをアップデートできます。アップデートは、通常のインストールと同じように開始されます。
サービスパック4 ISOイメージは、http://download.suse.com/から取得できます。これをDVDに書き込むか、14.2項 「インストールソースを保持するサーバのセットアップ」の説明に従ってネットワークインストールソースを準備します。
SUSEではバックポートを広範囲に使用します。このセクションでは、ソフトウェアの機能と問題を判断するためにバージョン番号を比較しても当てにならない可能性がある理由について説明します。
アップストリームの開発者は、自分が開発するソフトウェアを前進させることを念頭に置いています。多くの場合、バグの修正と新機能の導入が組み合わせられますが、その新機能は詳細なテストをまだ受けていないために、新しいバグを生み出す可能性があります。
配布物の開発者としては、次のものを見分けることが重要です。
バグ修正(機能を中断する限定的な可能性がある)。
変更(既存の機能を中断する可能性がある)。
多くの場合、パッケージがリリースされた配布物の一部になったら、配布物の開発者はアップストリームでのすべての変更を追うことはしません。通常は、最初にリリースされたアップストリームバージョンから離れずに、アップストリームの変更に基づいてパッチを作成してバグを修正します。こうした一連の処理はバックポートと呼ばれています。
一般的に、配布物の開発者が新しいバージョンのソフトウェアを導入するのは、次の2つの場合のみです。
パッケージとアップストリームバージョンの変更内容の差があまりに大きくなり、バックポートが不可能になってしまった場合。
本質的に経年劣化するソフトウェア(マルウェア対策ソフトウェアなど)。
SUSEでは、エンタープライズソフトウェアに対する数多くの考慮事項のバランスをうまく取るために、広い範囲でバックポートを使用しています。こうした考慮事項のうち最も重要なものは次のとおりです。
SUSEのエンタープライズ製品上で使用する製品を構築する際にソフトウェアベンダーが信頼することのできる安定したインタフェース(API)を提供すること。
SUSEのエンタープライズ製品のリリースで使用するパッケージが、単体としてもエンタープライズ製品全体の一部としても、最高品質であり、完全にテスト済みであることを確認すること。
SUSEのエンタープライズ製品に対するその他のベンダーによるさまざまな証明書を維持すること(OracleまたはSAP製品の証明書など)。
SUSEの開発者が、リリース全体に薄く広く注意を拡散させる必要なく、できるだけ優れた次のバージョンの製品の開発に集中できるようにすること。
特定のエンタープライズ向けリリースの内容の明確性を保ち、サポートがそのリリースについて正確かつタイムリーな情報を提供できるようにすること。
一般的なポリシールールとしては、当社のエンタープライズ製品に、パッケージの新しいアップストリームバージョンは導入されないことになっています。ただしこのルールは絶対的なものではありません。限られたクラスのパッケージ(特定のウィルス対策ソフトウェア内)では、品質確保の観点から選ばれた保守的なアプローチよりも、セキュリティに関する考慮事項の方が重視されます。こうしたクラスのパッケージでは、時として、エンタープライズ製品ラインのリリース済みバージョンに、新しいバージョンが導入されることがあります。
その他のタイプのパッケージについても、バックポートではなく新しいバージョンの導入が選択される場合があります。バックポートの作成が経済的に不可能な場合や、新しいバージョンの導入に対する非常に妥当な技術的な理由が存在する場合などがこれに該当します。
バックポートが実行されているために、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」(実際は脆弱ではないのに、ソフトウェアに脆弱な部分が見つかったというクレーム)が生成される傾向があります。セキュリティスキャンツールによるレポートを評価する場合は、エントリがバージョン番号のみに基づくものなのか、脆弱性が本当に存在するかどうかに関する実際のテストに基づくものかを、常に調査する必要があります。
Atomicアップデートは、システムの2つのコピーを管理し、更新失敗後の容易な復元を可能にするツールに基づいています。提供されたツールを使用するには、特別なディスクパーティション設定が必要です。システムの各コピーは、それ独自のプライマリパーティションに常駐します。更新が失敗した場合、常に、システムの前の状態(もう一方のパーティションで利用できる)に戻ることができます。
![]() | 厳格なパーティション分割要件 |
|---|---|
実装では、ディスクパーティションに関する厳格な要件があります。つまり、最初のルートパーティションは、
ディスク全体のサイズ- | |
/dev/sda1が単一のルートパーティションとして全ディスクサイズの半分未満を占めるシステムをインストールします。
インストールしたシステムを、必要に応じてカスタマイズします。multi-update-toolsパッケージを必ずインストールしてください。
multi-update-setup --partitionを実行します。このコマンドは、同様のサイズでシステムの2つ目のルートパーティション(/dev/sda2)を作成します。
必要に応じてディスクの残りをパーティション分割し、カスタマイズ(*)を続行します。
multi-update-setup --cloneを実行して、システムをもう一方のパーティションにコピーします。このコマンドで、ターゲットシステムの/etc/fstabにある/ (ルート)エントリも変更します。
必要に応じて、さらにカスタマイズ(*)します。
multi-update-setup --bootloaderを実行して、ブートローダの設定を初期化します。ブートローダのメニューに、もう一方のシステムをブートするためのエントリが組み込まれます。
![]() | 必須のGRUBブートローダ |
|---|---|
GRUBブートローダのインストールは必須です。それらのツールは、他のブートローダと互換性がありません。 | |
(*)でマークされたカスタマイズがない場合は、multi-update-setup --completeを使用して3つのステップをすべて実行します。
multi-updateを実行します。このコマンドは、chroot環境でzypperを実行し、もう一方のシステムを更新します。どちらのシステムがアクティブかは重要でありません。そのブートメニューは、ブート時にデフォルトとして表示されます。
更新したシステムのブートローダが更新後に破損している場合は、「アクティブ」フラグを変更して、もう一方のシステムのルートパーティション用に設定し、そのシステムをブートできるようにする必要があります。
更新したシステムがまったくブートしない場合は、ブートローダメニューにアクセスしてもう一方のシステムを選択する必要があります。
GRUBの詳細については、第11章 ブートローダGRUB (↑管理ガイド)を参照してください。
ルートパティションは、パーティション名またはIDによってマウントするか、その他の方法でマウントする必要があります。パーティションUUIDやラベルによるマウントはサポートされていません。
詳細については、multi-update-toolsパッケージに同梱されている/usr/share/doc/packages/multi-update-tools/READMEを参照してください。
マイグレーションフックによって、マイグレーションプロセスの過程のどこかの時点で、カスタムの外部スクリプトを実行できます。これらのスクリプトを使用して、通常のRPMスクリプトでは処理できない特定の問題を処理したり、マイグレーション中に必要とされるような(通常のパッケージアップデートでは必要とされない)追加のアクションを実行することができます。
マイグレーションフックはルート権限で実行されるので、スクリプト内では任意の保守タスクを実行できます(サービスの開始/停止、データのバックアップ、データマイグレーションなど)。これらのスクリプトは対話型にはできません。YaSTでの実行中にSTDINおよびSTDOUTがパイプにリダイレクトされます。Xセッションは使用できません。すべてのケースで使用できるとは限らないからです(テキストモードで実行中の場合など)。フックスクリプトについては、実行可能パーミッションを設定することを忘れないでください。
マイグレーションフックは、yast2-wagonパッケージのバージョン2.17.32.1 (SLES11-SP2に対するアップデートとして提供)または2.17.34 (SLES11-SP3に含まれる)以上でサポートされています。
これらのスクリプトは、/var/lib/YaST2/wagon/hooks/ディレクトリで見つけることができます。想定されるスクリプト名の形式は、step_seq_prefix_nameです。各文字列は次のような意味になります。
step
事前定義されたマイグレーションステップ名で、現在のマイグレーションステップを説明します。
seq
00~99までのシーケンス番号で、これによりスクリプトの実行順序を設定することができます(正しくソートするためには、必ず00から開始することが重要です)。
prefix
競合を避けるために一意にする必要があります(ネームスペースのように)。(パッケージの一部であれば)パッケージ名、またはベンダ名やインターネットドメイン名などを使用します。一意であると十分に考えられるものであれば基本的に何でも使用できます。
name
任意の文字列にできます(スクリプトを区別するだけのものです)。わかりやすい名前にすることをお勧めします。
スクリプトは終了値0を返す必要があります。失敗した(終了値がゼロ以外の)場合は、Wagonにエラーメッセージが表示され、スクリプトを再起動するか、失敗を無視(別のスクリプトで続行)するか、現在のステップおよびステージのフックを完全にキャンセルすることができます。
フックスクリプトは何度も実行される可能性がある(Wagonのダイアログを行き来しているうちに、Wagonそのものが再起動したり、マイグレーションワークフロー内で一部のステップが複数回実行される可能性もある)ので、スクリプトはその事実に対処する必要があります(アクションを実行する必要があるのか、アクションはすでに実行済みなのか、単純な一時的なスタンプファイルを作成できるのか、そうでなければ複数回の実行を正しく解決できるのかを、最初に確認することができます)。
一部のフックはオプションです(以前の結果またはユーザ選択の値に依存しているため)。一部のフックは複数回呼び出されるので注意が必要です(たとえば、登録はマイグレーションの前後に呼び出されます)。次に、サポートされているフック(ステップ名)を実行順に並べたリストを示します。
最初に開始されます(注意: Wagonの再起動後にもう一度呼び出されます)。
[ようこそ]ダイアログが表示される前後に開始されます。
Wagonが登録状態をチェックします(一部の製品の登録の期限が切れていると、マイグレーションに失敗する場合があります)。すべてがOKの場合は何もダイアログが表示されず、Wagonによって自動的に次のステップに進みます。
リポジトリマネージャが開始されます(オプション、パッチCDモードのみ)。
Wagonのアップデートそのものの前後に呼び出されます(最新バージョンがマイグレーションに使用されていることを確認します)。
マイグレーション製品のインストールの前後に呼び出されます。
Novell Customer Centerリポジトリ経由でマイグレートするのか、カスタムリポジトリを使用してマイグレートするのか、Wagonがユーザに尋ねます。次のステップはこのユーザ選択によって決まります。
SUSEレジスタが実行されます(マイグレーションリポジトリを追加するため)。
手動のリポジトリ管理。
マイグレーションリポジトリ(Novell Customer Centerの使用時は完全/最小マイグレーション)を選択するか、リポジトリ選択を更新します(カスタムリポジトリマイグレーション)。
パッケージのアップデートが開始される前、このステップの後に実際のマイグレーションが開始され、前の状態に自動的に戻ることはできなくなります(このフェーズで中止すると、システムに矛盾が発生し(半分アップグレードされた状態)、手動のロールバックが必要になります)。
SUSEレジスタが実行されます(アップデートされた製品を登録するため)。
マイグレーションが成功した結果、Wagonによって成功を示すダイアログが表示される前後。
Wagonが終了する直前に呼び出されます(中止後や再起動時も含め、マイグレーションの結果に関係なく常に呼び出されます)。
ユーザがマイグレーションを中止したときに呼び出される、特別な中止のフックがあります。これらのフックはマイグレーションワークフロー内の任意のステップで呼び出すことができるので、実行順序は保証できません。他のフックの結果に依存している場合、スクリプトで現在の状態をチェックする必要があります。
ユーザがマイグレーションの中止を確定しました。
ユーザが中止後にロールバックを確定しました(マイグレーション開始前にインストールされていた古い製品に戻ります)。これらのフックはbefore_abortの後に呼び出され、ユーザがロールバックを確定しない場合はスキップされます。
これらのフックは、Wagonそのものが再起動されると常に呼び出されます。
Wagonは終了し、もう一度開始されます。
Wagonは再起動されており、マイグレーションワークフローの次のステップが実行されます。
フックのリストはかなり大きなものですが、その多くは特別な事例で意味をなすものです。通常の使用例では、次のようなフックが優先的に使用されます。
システムをマイグレートする前(まだ前のバージョンを実行しているとき)に何らかのアクションを実行するには、before_package_migrationフックを使用します。
この時点では、マイグレーションの準備ができていて開始寸前であることは明確ですが、それ以前のすべてのステップで、マイグレーションを中止することが可能でした。
システムのマイグレート後(システムはマイグレード後の新しいバージョンを実行しているが、何かまだアクティブになっていない機能があるとき(カーネルのアップデート後にリブートが必要だったり、サービスのアップデート後に再起動が必要な場合など))に何らかのアクションを実行するには、before_congratulateまたはafter_congratulateフックを使用します。
これは、before_package_migrationフックによる一時的な結果を消去する場合にも使用できます。この時点で、マイグレーションは正常に終了しています。
マイグレーションが中止された場合に変更を元に戻すには、事例に応じて、中止のフックのいずれかを使用します。中止のフックはいつでも呼び出すことができるので、元に戻す必要はないかもしれません(変更を実行するフックがまだ呼び出されていない可能性があります)。中止のフックでは、現在の状態をチェックする必要があります。
古いバージョンのWagonでは、2つのフックスクリプトのみがサポートされていました。/usr/lib/YaST2/bin/wagon_hook_initと/usr/lib/YaST2/bin/wagon_hook_finishです。問題は、フックとして実行できるスクリプトは1つだけで、フックを直接PRMパッケージに配置できないことでした。
これらの古いフックスクリプトは、後方互換性のために新しいバージョンのWagonでもサポートされていますが、廃止されたフックの変わりに、新しいフックのbefore_initとbefore_exitを使用する必要があります。