AIX のファイルセット更新：Apply・Commit・Reject の違いを整理する

はじめに

AIX のファイルセット更新における Apply、Commit、Reject の違いを簡単に整理しました。

この記事では、以下の内容を扱います。

• Apply・Commit・Reject の違いと、SP 更新の基本的な流れ
• smitty update_all での Commit／Apply の指定方法
• ファイルセットの状態（APPLIED／COMMITTED）の確認方法
• Apply を指定しても自動 Commit されるケース
• 更新作業のポイント（バックアップ、プレビュー、整合性確認など）

---

参考動画

当記事の参考動画です

---

用語

用語	意味
ファイルセット	個別のソフトウェアを管理する単位
TL（Technology Level）	機能拡張や修正などを含む AIX の更新レベル
SP（Service Pack）	主に不具合修正などをまとめた更新
smitty	メニュー画面で対話的に操作できる AIX の管理ツール
mksysb	rootvg（OS を含むボリュームグループ）のシステムバックアップを作成するコマンド
切り戻し	更新前の状態に戻すこと
依存関係	あるソフトウェアの動作に、別のソフトウェアや特定のバージョンが必要になる関係

Apply・Commit・Reject の違い

操作	内容
Apply	更新を適用し、切り戻し用の旧ファイルを残す
Commit	更新を確定し、旧ファイルを削除する
Reject	未 Commit の更新を取り消して、以前のレベルに戻す

SP 更新で、動作確認後に Commit する場合の流れは以下のとおりです。

1. Apply で更新を適用する。
2. 必要に応じて再起動し、正常に動くか確認する。
3. 問題がなければ Commit する。問題があれば、Reject の可否やバックアップからの復旧を検討する。

SP 更新でも、自動 Commit されるファイルセットや、依存関係の都合により、Reject だけでは更新前の状態に戻せないことがあります。
更新前に mksysb などで復旧手段を用意しておくと安心です。自動 Commit とバックアップについては、後ほど説明します。

押さえておきたいポイントは以下の 3 つです。

• Apply が完了した時点で、ファイルセットの更新は適用されています。 Commit は更新を有効にする操作ではありません。ただし、カーネルの更新など、再起動しないと実際の動作に反映されないものもあります。
• Commit 後は Reject できません。 切り戻し用の旧ファイルが削除されるためです。
• TL の更新は Commit する前提です。

参考：IBM：AIX Service Strategy and Best Practices

smitty update_all での指定方法

smitty update_all の更新画面には、以下の項目があります。

  COMMIT software updates?                            yes
  SAVE replaced files?                                no

項目	意味
COMMIT software updates?	更新を確定するか
SAVE replaced files?	置き換え前のファイルを保存するか

上記は Commit する設定の例です。Commit せずに Apply のみにする場合は、COMMIT software updates? を no、SAVE replaced files? を yes にします。

Commit すると旧ファイルは削除されるため、両方を yes にすることはできません。

参考：IBM：TL／SP 更新手順

状態の確認方法

lslpp -l でファイルセットの状態を確認できます。以下は、AIX カーネルのファイルセット bos.mp64 を確認する例です。

# lslpp -l bos.mp64
  Fileset                      Level  State      Description
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.mp64                  7.2.5.1  APPLIED    Base Operating System 64 bit
                                                 Multiprocessor Runtime

Path: /etc/objrepos
  bos.mp64                  7.2.5.1  APPLIED    Base Operating System 64 bit
                                                 Multiprocessor Runtime

この記事では、State 列に表示される状態のうち、APPLIED と COMMITTED を扱います。

状態	意味
APPLIED	更新は適用済み。まだ Commit していない
COMMITTED	更新が確定している

APPLIED は異常ではありません。 更新は適用されており、Commit を保留しているだけの状態です。

そのほか、よく使う確認コマンドは以下です。いずれも表示のみで、更新は実行しません。

# 未 Commit の更新一覧
installp -s all

# OS 全体の TL／SP レベル
oslevel -s

Apply の指定でも、自動 Commit されることがある

TL／SP の更新モジュールには、更新イメージだけでなく、ソフトウェア本体を含むベースインストールイメージが含まれることがあります。

ベースインストールイメージは、Apply のみを指定しても自動 Commit されます。 見分けるには、導入前に次のコマンドで一覧を表示し、I(Install image)/U (Update image) 列を確認します。

installp -qld /path/to/image

/path/to/image には、SP や TL の更新モジュールを配置したディレクトリーを指定します。このコマンドは内容を表示するだけで、インストールは実行しません。

例えば、更新モジュールを /mnt に配置した場合は、以下のようになります。1 行目の # はプロンプト、2 行目以降の # で始まる行はファイルセットの説明です。

# installp -qld /mnt
  Fileset Name                Level                     I/U Q Content
  ====================================================================
  ICU4C.adt                   7.2.5.0                    I  N usr
#   ICU Application Developer's Toolkit

  ICU4C.rte                   7.2.5.0                    I  N usr,root
#   International Components for Unicode

  Java6.samples.demo          6.0.0.655                  S  N usr      (R)
#   Java SDK 32-bit demo Samples

  Java6.samples.jnlp          6.0.0.650                  S  N usr      (R)
#   Java SDK 32-bit jnlp Samples

  Java6.sdk                   6.0.0.655                  S  N usr,root (R)
#   Java SDK 32-bit

(出力省略)

I(Install image)/U (Update image) 列（主な値）	イメージの種類	Apply のみを指定した場合
I	ベースインストールイメージ（ソフトウェア本体）	自動的に COMMITTED になる
S	単一の更新イメージ	APPLIED として保持できる

イメージの種類はファイル名からは判別しにくいため、出力の I(Install image)/U (Update image) 列で確認します。表以外の値が表示される場合もあります。

更新作業のポイント

更新前に mksysb を取得する

Commit 後は Reject できないため、更新前に mksysb でバックアップを取っておくと安心です。 TL の更新のように Reject できない場合も、更新前の状態に戻す手段になります。

mksysb のバックアップ対象は、rootvg 内でマウントされている JFS／JFS2 ファイルシステムです。rootvg 以外に保存しているデータは、別途バックアップが必要です。

まずプレビューで確認する

smitty update_all の画面で PREVIEW only? を yes にすると、実際には更新せずに、依存関係の不足や空き容量不足などを事前に確認できます。

  PREVIEW only? (update operation will NOT occur)     yes

更新後に整合性を確認する

lppchk -v で、ファイルセットの依存関係に不整合がないかを確認できます。問題がなければ何も表示されません。

lppchk -v

動作確認後に Commit／Reject する

Apply のみで更新した場合は、動作確認の後に以下で Commit または Reject します。

操作	smitty	コマンド
未 Commit の更新をすべて Commit	smitty commit	installp -c all
指定したファイルセットの更新を Reject	smitty reject	installp -r ファイルセット名

installp -c all は、今回の作業以前から残っているものも含め、未 Commit の更新すべてを対象にします。対象は installp -s all で確認できます。

APPLIED の状態では、切り戻し用の旧ファイルがディスク容量を使用します。動作確認や運用上の確認期間が済んだ段階で、Commit するかを判断するとよいでしょう。

おわりに

Apply、Commit、Reject の違いと、状態の確認方法、更新作業のポイントをまとめました。
AIX の更新作業の参考になれば幸いです。

以上です。

参考資料

• IBM：installp コマンド
• IBM：lslpp コマンド
• IBM：lppchk コマンド
• IBM：AIX Service Strategy and Best Practices
• IBM：TL／SP 更新手順