Red Hat Enterprise Linux (RHEL)を使う前にサポート要件やライフサイクルの考え方、更新の案内、rpmパッケージ、SLAなどについてざっくりまとめた資料。 社内で新しく入社した人むけにまとめた資料。 一般にも便利そうなので公開します。もろもろ省略されているので正確な情報は各リンク先などを参照。
Red Hat Enterprise Linux を
使う前に読む資料
森若和雄 kmoriwak@redhat.com
2020-01-27
Red Hat K.K. All rights reserved.
1
agenda
認定・ライフサイクル・延長サポート製品
Red Hat Network, rpm, yum, errata
RPMパッケージの基礎
障害時の情報収集、サポート窓口、ケースの扱い
upstream first policy
Red Hat K.K. All rights reserved.
2
認定・ライフサイクル・延長サポート製品
Red Hat K.K. All rights reserved.
3
各種認定の確認
サポートされる環境を整える
ハードウェアの認定
●
レッドハットによる認定
●
https://catalog.redhat.com/
ISV製品の認定
●
ISVによる認定
●
●
Red HatではなくISV各社に確認
利用予定のアプリケーション開発ベンダへ動作環境をご確認頂く必要があります
ストレージの認定
●
ストレージベンダによる認定
●
●
Red Hatではなくストレージベンダ各社に確認
利用予定のストレージベンダへ対応OSをご確認頂く必要があります
Red Hat K.K. All rights reserved.
4
OEM版RHELのサポートについて
レッドハットのRHELについてのサポートポリシーは今までの通
りですが、OEM版RHELは異なることがあります
OEMパートナが別途定めたポリシーによってサポート内容が決定
されます
●
特定ハードウェア上で動作することが必要
●
特定パッケージはサポート対象外
など
詳細はOEM各社にご確認ください
●
「レッドハットの製品ではない」のでレッドハットは回答できません
Red Hat K.K. All rights reserved.
5
RHELの製品ライフサイクル
https://access.redhat.com/support/policy/updates/errata/
Red Hat Enterprise Linux versions 5, 6 and 7
Red Hat Enterprise Linux version 8
Red Hat K.K. All rights reserved.
6
RHELのリリース
メジャーバージョン、メジャーリリース (RHEL X)
●
例: RHEL4, RHEL5, RHEL6
●
変更点: 基本的に別の製品(アップグレードは可能)
●
●
主要ライブラリについては互換のため1つ前の製品と同じ版を含む
頻度: およそ3年に1回メジャーリリースを出荷
アップデートリリース、マイナーリリース (RHEL X.Y)
●
例: RHEL5.7, RHEL5.8, RHEL6.3
●
変更点: 新規パッケージの追加や機能拡張を含む
●
頻度: およそ半年に1回アップデートリリースを出荷
アップデートの途中で出荷される修正 (RHEL X.Y.Z)
●
変更点: 重要なセキュリティ問題やバグの修正。機能拡張は行わない
●
頻度: 特に回数は決まっていない
Red Hat K.K. All rights reserved.
実際には
番号はつきません
z-stream や
非同期errataと
呼ばれています
7
通常のRHELサポート
新しいアップデートリリースが出荷されると今までのアップデー
トリリースのサポートは終了します
●
●
たとえばRHEL6.4が出荷されると、RHEL6.3までのバージョンはサポート対象では
なくなります
利用そのものは問題ありません
古いアップデートリリース用の修正は出荷されません
●
たとえばRHEL6.4で修正された問題について、「RHEL6.3用の修正がほしい」とリ
クエストしても
「RHEL6.4で修正されているのでアップデートして対応してください」と回答しま
す
時間
6.0
6.1
6.2
Red Hat K.K. All rights reserved.
6.3
6.4
8
RHEL開発ツリーとアップデートリリース
RHEL6.5
6.0がメンテナンス
されるのは
6.1が出荷されるまで
6
L
E
H
R
ツ
発
開
ー
リ
（
キ
セ
ィ
テ
リ
ュ
グ
バ
,
fix
能
機
,
fix
張
拡
)
RHEL6.4
RHEL6.3
RHEL6.2
RHEL6.1
6.1リリース
RHEL6.0
QA期間
約6ヶ月
Red Hat K.K. All rights reserved.
時間
9
アップデートリリース間のアプリケーション互換性
「移行計画ガイド」からの抜粋
1.2. アプリケーションの互換性
(中略)
Red Hat Enterprise Linux のマイナーリリース間ではアプリケーションの再テス
トや再認定は必要ありません。 Red Hat Enterprise Linux の互換性ポリシーで
は、 そのリリースの任意のバージョンで実行しているアプリケーションはそのリ
リースのライフ期間中を通じて継続的に実行することを保証しています。 例え
ば、 Red Hat Enterprise Linux 6.0 で認定されたアプリケーションは Red Hat
Enterprise Linux 6.1 などの全マイナーリリースで完全な互換性を持つことになり
ます。
※上記はRed Hatのポリシーで、他社製ソフトウェアのサポート要件は各ISVによ
り異なります。
https://access.redhat.com/knowledge/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Migration_Planning_Guide/ch01s02.html
Red Hat K.K. All rights reserved.
10
新機能導入
新機能はアップデートリリースとメジャーリリースのタイミング
で導入
主要な新機能についてはドキュメント「Release Notes」で紹介
●
●
RHEL 5,6では細かな違いの詳細についてはドキュメント「Technical Notes」で紹
介
サポート対象外の機能(テクノロジープレビュー)もこの文書で案内
製品ドキュメント
●
https://access.redhat.com/knowledge/docs/
Red Hat K.K. All rights reserved.
11
新機能が入るタイミング
RHEL6.5
ここまでの
変更を
まとめて6.1に
QAします
新機能
つくったよ
6
L
E
H
R
6.1として
出荷
ツ
発
開
ー
リ
セ
（
ュ
キ
ィ
テ
リ
グ
バ
,
fix
拡
能
機
,
x
fi
)
張
RHEL6.4
RHEL6.3
RHEL6.2
RHEL6.1
6.1リリース
RHEL6.0
QA期間
時間
Red Hat K.K. All rights reserved.
12
重要な修正の導入
深刻なバグや、セキュリティ上の問題についてはアップデートリ
リースを待たずに導入します
開発者が準備した修正を、現在サポート中およびQA中のリリー
ス用に同梱します
●
ほとんどの場合は同一のものですがアップデートリリースでパッケージのバージョ
ンが異なる場合には複数バージョンで同一問題への対応がおこなわれます
Red Hat K.K. All rights reserved.
13
重要な修正のタイミング
RHEL6.5
6.2は最初から
対応済み
6.0, 6.1それぞれに
反映するよ
E
RH
L6
ツ
発
開
ー
リ
6.1は
リリース時には
修正済み
RHEL6.2
問題を
なおしたよ
RHEL6.4
RHEL6.3
RHEL6.1
6.0は
非同期errata
6.1リリース
リリース
RHEL6.0
QA期間
時間
Red Hat K.K. All rights reserved.
14
Extended Life-cycle Support(ELS)
RHEL 5(2020年11月まで), RHEL 6(2020年12月から) のサポート
期間を延長します
10年間の標準ライフサイクルに対して一部ソフトウェアのみサ
ポート期間を延長
●
ELSを購入しない場合、一切更新が行われないELP(Extended Life-cycle Phase)にな
ります
通常のサブスクリプションに追加で購入するAdd-onサブスクリ
プション
サポート対象は限定的なので注意
●
https://access.redhat.com/articles/2901071
Red Hat K.K. All rights reserved.
15
Extended Update Support(EUS)
一部のパッケージについて、アップデートリリースのサポート期
間を24ヶ月に延長します(半年おきに出荷とすると18ヶ月延長)
延長された期間の間、以下がバックポートされます
●
重大影響度のRHSAと
●
一部の緊急優先度のRHBA
「アップデート実施回数の削減」が可能になります
●
例: 完全にサポートされた状態でRHEL6.0を使いつづけ6.1, 6.2をスキップしたのち
6.3へ移行
6.0
6.1
6.2
6.3
6.4
6.0 EUS
6.1 EUS
6.2 EUS
Red Hat K.K. All rights reserved.
16
EUSの詳細
EUSが利用可能なマイナーバージョンはバラバラなのでRHELの
ライフサイクルページを確認するのがよい
●
https://access.redhat.com/support/policy/updates/errata/#Extended_Update_S
upport
EUSで対象になるパッケージ
●
RHEL 7 https://access.redhat.com/node/4082531
●
RHEL 8
●
セキュリティfixはEOLになっていないパッケージのCriticalとImportant全て
●
●
Application Stream等で非同期にEOLになるパッケージがある
バグ修正は最低限以下が対象。これ以外もRed Hatの裁量で追加。
bind, bash, chrony, grub2, grubby, glibc, gnutis, kernel, libgcrypt, libvirt, nss,
openssh, openssl, python 3.6, qemu-kvm, rpm, sudo, systemd, wget, yum /
dnf
Red Hat K.K. All rights reserved.
17
EUSでの修正提供 (RHEL6.2)
RHEL6.5.z
バグ直したよ
RHEL6.4.z
それぞれに
修正を
反映します
6
L
E
H
R
発
開
リ
ツ
RHEL6.3.z
ー
EUSご購入のお客様のみ
RHEL6.2.z
RHEL6.2 EUS
RHEL6.1.z
6.1リリース
RHEL6.0.z
QA期間
24ヶ月
Red Hat K.K. All rights reserved.
時間
18
EUSの必要有無
EUSが不要なケース
●
ISVなどの要件がRHEL5, RHEL6 のようなメジャーリリースだけを指定している
●
機能拡張を含む更新を導入したい
●
修正が出てもソフトウェアの更新は一切おこなわない
EUSが必要なケース
●
●
●
ISVなどの要件が “RHEL 6.2” のようにアップデートリリースを指定する
機能拡張はしたくないが、深刻なバグとセキュリティ上の問題に対する修正は導入
したい
必要なソフトウェアがEUSでサポート対象になっている
https://access.redhat.com/node/4082531
Red Hat K.K. All rights reserved.
19
古いマイナーリリースを使いつづけた場合のサポート
ポリシーが文書化され公開されています
●
ざっくりまとめると以下のようなポリシーです
「お客様には古いリリースを使う自由があります。ただし現在サ
ポート対象となっているアクティブなリリースとの差分を埋める
のはお客様の責任です。」
そのため、古いリリースを使いつづける場合は以下を検討します
●
https://access.redhat.com/articles/64664
問題が発生した場合にRHELの一部または全部を最新リリースへ更新して問題が再
現するか確認するための検証環境の用意
「更新しないでいい理由を探す」ことや「なぜ更新が必要かの説
明をする」ことはサポート窓口ではおこないません
●
RHELは定期的に更新しつづけることが前提です。変則的な利用は禁止されていませ
んがその支援は特に行いません。
20
Red Hat K.K. All rights reserved.
Red Hat Network、rpm、yum、errata
Red Hat K.K. All rights reserved.
21
Red Hat Network とは
RHELおよび関連製品の管理・更新のための仕組み
●
インストールに利用するISOイメージのダウンロード
●
個別rpmパッケージのダウンロード
システムをRed Hat Networkに登録して以下のようなサービスを
利用する
●
add-on製品などを必要なサーバに割り当て・インストール
●
追加・更新パッケージの取得
●
各サーバのパッケージ状態の確認・管理
●
●
状態を登録しないこともできます
利用中のシステムに関連する更新情報を通知・確認
Red Hat K.K. All rights reserved.
22
RHELの一般的な管理モデル
システム管理
ソフトウェアの配布
アカウントの管理
サブスクリプションの管理
https
Proxy
Red Hat Networkを利用
●
インターネット接続を利用できる場合
●
全サーバを rhsm.redhat.com に登録
●
各サーバは cdn.redhat.com からパッケージを取得
●
Web UIはaccess.redhat.comから参照
Red Hat K.K. All rights reserved.
23
Red Hat Networkの用語
リポジトリ(repository)
●
●
rpmパッケージのセットをリポジトリと呼んでいる
リポジットリには “Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64” のよう
な名前がついている
●
各システムはこのリポジトリを講読(subscribe)する
●
yumコマンドで講読したリポジトリに含まれるrpmを取得できる
サブスクリプション(subscription)
●
どの製品を、いつからいつまでの期間、何本利用できるか
●
製品を購入すると、1つ以上のサブスクリプションが付与される
●
システムが登録されるとサブスクリプションと対応づけられる(対応づけできないと
更新などのサービスを受けられない)
Red Hat K.K. All rights reserved.
24
カスタマポータル(access.redhat.com)
→サブスクリプション→システム
Red Hat K.K. All rights reserved.
25
各システムのページ
Red Hat K.K. All rights reserved.
26
非インターネット環境におけるRHEL管理モデル
システム管理
ソフトウェアの配布
アカウントの管理
サブスクリプションの管理
オフライン
Satellite
ソフトウェアの配布
RHNと配布サーバの同期がポイント
●
完全にオフラインの場合: Red Hat SatelliteがRed Hat Network相当+αの機能を提供
●
Red Hat Smart Managementで提供
●
自社専用Red Hat Networkを実現する別売り管理製品
●
管理や自動化を支援する付加機能
●
Satelliteはデータをオンラインで同期できるほか、ISO形式で提供されるためオ
フラインでの同期も可能
Red Hat K.K. All rights reserved.
27
rpmコマンドとyumコマンド
rpmコマンド
●
rpmパッケージをインストール・削除・更新する
●
●
インストール時には依存関係を認識して不足パッケージがあれば通知
現在は主に情報収集やパッケージ内容の確認などに利用する
yumコマンド
●
依存関係の自動解決を行いつつ、rpmパッケージを管理する
●
パッケージの追加・削除をともなう管理はyumに集約する
●
リポジトリ外のRPMパッケージをyumコマンドで導入する場合は以下のコマン
ドラインを使用
●
yum localinstall URI
●
例) yum localinstal http://www.example.com/path/to/rpm/file.rpm
●
yum localinstall path/to/rpm/file.rpm
Red Hat K.K. All rights reserved.
28
アドバイザリの適用
RHEL 5 Server x86_64
...........
...........
...........
5.4
...........
...........
...........
...........
...........
...........
...........
...........
5.3
5.5
Errata
アドバイザリの適用 = RHEL特有のソフトウェア保守作業
システムの健全性 (正確性、安全性、堅牢性) を保つため、最新
のアドバイザリの適用を推奨
アドバイザリの種類 (詳しくは後述):
●
セキュリティ アドバイザリ
●
バグ アドバイザリ
●
機能拡張 アドバイザリ
Red Hat K.K. All rights reserved.
29
アドバイザリとOSアップデートリリースの関係
アップデートリリース：
RHEL6.0 → 6.1 → 6.2...
●
およそ6ヶ月毎のリリースサイクル
●
ソフトウェアバージョンおよびAPI/ABIをできるだけ維持
アップデートリリースの実体
●
アドバイザリの集合
●
以下の2つは基本的に全く同じもの*1
●
RHEL6.4 GA
●
RHEL6.3にRHEL6.4時点のアドバイザリを適用したもの
*1 実際にはRHEL6.4リリース日に提供される0dayエラータがあるのでぴったり合
わせることは難しい
Red Hat K.K. All rights reserved.
30
アドバイザリとは
製品の修正や拡張は全てアドバイザリ(Advisory, errataとも)とよ
ばれる形で提供される
●
各アドバイザリにはRPMパッケージが含まれる
●
一つのアドバイザリによって1つ以上の問題の修正に対応
●
あるアドバイザリはそれ以前のアドバイザリが全て適用された状態で検証済み
「パッチでの配布」との違い
●
●
あるパッケージについて、特定の修正だけを選択的に適用する方法は無い
例: バグ修正が3回おこなわれたあとセキュリティ上の問題に対する修正がおこなわ
れた。 セキュリティ上の問題に「だけ」対応したい→NG
●
検証するバリエーションが減る
●
QAされたものだけを利用できる
Red Hat K.K. All rights reserved.
31
アドバイザリ一覧の例:
https://access.redhat.com/errata/
Red Hat K.K. All rights reserved.
32
アドバイザリの例:
https://access.redhat.com/errata/RHBA-2020:0089
Red Hat K.K. All rights reserved.
33
アドバイザリの種別 と ID
セキュリティ修正 ： Red Hat Security Advisory
●
セキュリティに関する修正
●
不定期に発行
バグ修正
： Red Hat Bug Advisory
●
不具合に関する修正
●
不定期に発行
機能拡張修正
： Red Hat Enhancement Advisory
●
機能拡張に関する修正
●
OSのアップデートリリースで発行
アドバイザリのID = RHXA-YYYY : NNNN(-Z)
●
X = S/B/Eのいずれか
●
YYYY = アドバイザリの元となった問題の報告された年号
●
NNNN = 年毎の通し番号
●
Z = アドバイザリに修正がおこなわれた場合の識別子、通常はつかない
Red Hat K.K. All rights reserved.
34
RHSA の影響度
Critical
●
このタイプの脆弱性は、ローカルユーザーによる権限の取得、認証されていないリ
モートユーザーによる認証保護リソースの閲覧、認証されたリモートユーザーによ
る任意のコードの実行、ローカルまたはリモートユーザーによるサービス拒否を可
能にします。
Moderate
●
このタイプの脆弱性は、ワームによる悪用が可能です。認証されたリモートユー
ザー、ローカルユーザー、または非現実的な設定を必要とする不具合は、重大な影
響には分類されません。
Important
●
https://access.redhat.com/security/updates/classification/
このタイプの脆弱性は、重大または重要な影響になる可能性はありましたが、不具
合の技術評価に基づいてあまり容易に悪用できないか、非現実的な設定に影響しま
す。
Low
●
このタイプの脆弱性は、悪用のためにはあり得ない状況が必要と思われるものや、
悪用が成功しても影響は最小であるものです。
Red Hat K.K. All rights reserved.
35
RPMパッケージの基礎
Red Hat K.K. All rights reserved.
36
RPMパッケージとは 1/3
RPMパッケージ = インストールの最小単位
●
●
RPMパッケージがインストールの有無を選択できる最小単位
目的や機能などでパッケージをまとめた「パッケージグループ」単位でのインス
トールも可能 (インストーラおよびyumコマンド)
RPMパッケージに含まれるもの:
●
●
●
プログラムファイル、設定ファイル、データファイル等インストールされるファイ
ル一式
インストール時、アンインストール時に実行されるアクション
メタデータ (パッケージ名、バージョン、リリース、提供者、ビルドホスト
名、GPG Key、依存関係)
Red Hat K.K. All rights reserved.
37
RPMパッケージとは 2/3
設定ファイル
など
プログラム、
ライブラリなど
メタデータ
パッケージ名、
バージョン、
説明、
依存関係など
(RPM)パッケージ
zlib-1.2.3-3.i386.rpm
その他データ
パッケージ = プログラムやデータファイル等をまとめたもの
+ メタデータ
RPM は RHEL で採用されているパッケージ形式
●
RPM = RPM Package Manager
●
http://rpm.org
Red Hat K.K. All rights reserved.
38
RPMパッケージとは 3/3
RHN Web でのパッケージメタデータ表示例
パッケージ名
●
アーキテクチャ、バージョン
●
概要説明
●
提供リポジトリ
●
変更ログ
など
●
Red Hat K.K. All rights reserved.
39
パッケージ vs. パッチ vs. アーカイブ
全データ
メタデータ
名前
バージョン
説明
依存関係等
(簡易)メタデータ
差分データ
(RPM) パッケージ
全データ
名前
バージョン
依存関係等
パッチ
zlib-1.2.3-3.i386.rpm
(tgz) アーカイブ
zlib-1.2.3.tar.gz
パッケージは完全なデータ一式を含む
パッチは適用対象が必要
tar+gzip/zip アーカイブなどには通常はメタデータが含まれない
●
アップデート/アンインストールが困難
Red Hat K.K. All rights reserved.
40
RHEL = RPMパッケージ集合 1/2
/
...
usr/
...
share/
...
lib/
...
...
doc/
...
libz.so.*
RHELシステ
ム
zlib-2.1.3/
zlib-1.2.3-3.i386.rpm
FAQ
README
RHEL ファイルシステム
RPM パッケージ
RHEL システムは RPM パッケージに含まれるデータで構成され
る
Red Hat K.K. All rights reserved.
41
RHEL = RPMパッケージ集合 2/2
httpd-2.2.3-43.el5.i386.rpm
mysql-5.0.77-4.el5.i386.rpm
RHELシステム
(コンポーネン
ト構成の視点か
ら)
httpd mysql
app1
zlib, etc.
glibc
Kernel
app1-x.y.z-1.i386.rpm
zlib-1.2.3-3.i386.rpm
glibc-2.5-49.i686.rpm
kernel-2.6.18-194.el5.i686.rpm
RPM パッケージはRHEL システムを構成するソフトウェアコン
ポーネントの基本単位
Red Hat K.K. All rights reserved.
42
バイナリRPMパッケージのインストール
/
usr/
lib/
...
...
ファイルの展開と配置
...
バイナリ RPM を
インストール
RHEL システム
RHEL ファイルシステム
アクションの実行
インストール = ファイルの展開と配置 + アクションの実行
Kernel や glibc など核となるパッケージのアップデート時には更
新の反映のために、システムの再起動が必要
Red Hat K.K. All rights reserved.
43
バイナリRPMパッケージのアップデート
/
usr/
lib/
...
...
RHELシステ
ム
ファイルの展開と配置
(旧版の置き換え)
...
より新しいバイナリ
RPM をインストール
RHEL ファイルシステム
アクションの実行
アップデート = 旧版のアンインストール + 新版のインストール
ダウングレードについて
●
ダウングレード = アップデートの逆、旧版による新版の置き換え
●
多くの場合可能だが、必ず可能ではない
●
非可逆なアクションの逆方向への実行はむずかしい
●
複雑な依存関係 (Obsoletes) があるとより困難
Red Hat K.K. All rights reserved.
44
RPMパッケージの基礎 まとめ
RPM パッケージは RHEL システムの基本単位
●
バイナリ/ソース/Debuginfo パッケージ
●
サポート対象はバイナリ RPM のみ
バイナリパッケージ = 静的データ + アクション
●
依存関係はシステムの整合性を保つため
●
RPM のインストール = ファイルの展開、配置 + アクション実行
無視してはだめです。最悪の場合システムが壊れます!
パッケージのアップデート = 新規パッケージによる旧版の置き換
え
●
『パッチ』 は提供していません
●
必ずしもダウングレードは可能ではありません
Red Hat K.K. All rights reserved.
45
障害時の情報収集、サポート窓口、ケースの扱い
Red Hat K.K. All rights reserved.
46
障害対応の基礎
情報収集
●
初期の問題切り分け
●
●
問題切り分けの有無と正確さにより、その後の対応速度に大きな差が出ます
sosreport, kexec&kdump
サポートケースのオープン
●
カスタマーポータルもしくは電話にてケースオープン
※営業時間外でのケースオープン時にはカスタマーポータルでケース登録後に
電話での一報が必要
●
サポート担当者とのやりとりによる対応
Red Hat K.K. All rights reserved.
47
sosreport
各種ハードウェア/ソフトウェア環境情報を収集しアーカイブ
●
/etc、/var/log 内の主要な設定とログ
●
sosreport実行時の負荷状況取得
●
その他各種ソフトウェアに対応した設定情報・ログ取得
サポートチームが問題に対する前提条件をお客様と共有するた
め、ケースオープンの初動としてsosreportの出力結果の送付を
お願いする事が多くあります
●
ケースオープン時に"sosreport -a"の出力を添付しておくと早く対応開始できます
通常のtar ballなので送付前に秘密にしたい情報が含まれていな
いかチェック可能です
サポート問い合わせ時以外に、サーバの状態を記録する目的にも
応用できます
Red Hat K.K. All rights reserved.
48
sosreport
実行例
# sosreport -a
sosreport (version 2.2)
This utility will collect some detailed information about the
hardware and setup of your Red Hat Enterprise Linux system.
The information is collected and an archive is packaged under
/tmp, which you can send to a support representative.
Red Hat Enterprise Linux will use this information for diagnostic purposes ONLY
and it will be considered confidential information.
This process may take a while to complete.
No changes will be made to your system.
Press ENTER to continue, or CTRL-C to quit.
Please enter your first initial and last name [kmoriwak]:
Please enter the case number that you are generating this report for: 12341234
Running plugins. Please wait ...
Completed [55/55] ...
Creating compressed archive...
Your sosreport has been generated and saved in:
/tmp/sosreport-kmoriwak.12341234-20130207155145-2178.tar.xz
The md5sum is: b1add664051d3ddd1758f5f20a2d2178
Please send
fileAll
torights
your reserved.
support representative.
Redthis
Hat K.K.
49
sosreportの中身
各種状態確認コマンド出力、 /proc, /sys内容
各種ログ
設定ファイル
sarの監視情報
などなど
boot
chkconfig
date
df
dmidecode
etc
free
hostname
ifconfig
installed-rpms
java
lib
lsb-release
lsmod
lsof
lspci
lvmdump
mount
netstat
proc
ps
pstree
root
route
rpm-Va
sar07
sar31
sbin
sestatus
var
sos_commands vgdisplay
sos_logs
sos_reports
sys
uname
uptime
Red Hat K.K. All rights reserved.
50
kexec & kdump
障害によってメモリダンプ解析が必要になる場合があります
●
システムがpanicしてしまい、他に情報が残らない場合
●
カーネル内のバグが疑われる場合
RHELでは、kexec&kdumpと呼ばれる仕組みでメモリダンプを
取得します
kexec
●
カーネルが再起動をともなわずに別のカーネルをロード
●
本来は高速なリブートを実現するための仕組み
kdump
●
ダンプ専用カーネルを用意し、kexecを利用して実行
●
再起動をともなわないためメモリの情報が残っている
Red Hat K.K. All rights reserved.
51
サポートケースの新規作成
Red Hat K.K. All rights reserved.
52
作成したケースの確認
Red Hat K.K. All rights reserved.
53
サポートコールフロー
Red Hat K.K. All rights reserved.
54
重大度レベル(シビリティ)
サポートへの問い合わせ時に、問題のビジネスインパクトにより
1(緊急)から4(低)までの範囲で重大度を設定する
●
サポート対応時間に影響します
●
営業時間外に重大度1または2を登録する場合、ケース登録後にお電話ください
https://access.redhat.com/support/policy/severity/
以下は抜き書きです。正確な定義は上のURLに記載されています
重大度1 (緊急)
プロダクション用途に深刻な影響を及ぼす問題。 業務を停止せざるを得ない状況
で、回避策がない。
重大度2 (高)
プロダクション用途において、業務の一部に深刻な影響を与える状況で、回避策が
ない。
重大度3 (中)
プロダクション用途において、お客様のビジネスに中から低程度の影響があるが、
回避策があり、業務は続けられる場合。
開発用途において、プロジェクトを続行できない、またはプロダクションに移るこ
とのできない状態。
重大度4 (低)
一般的な使用に関する質問、文書エラーの報告、将来の製品改善または修正の推
奨。 プロダクション用途において、システムの機能や性能、またはビジネスへの影
響が低い、もしくは無い。 開発用途において、ビジネスに中から低程度の影響があ
Red Hat K.K. All rights reserved.
るが、回避策があり、業務は続けられる。
55
重大度とSLA
重大度およびサポートのレベルにより対応時間のSLAが
変わります
Standard
対象時間
営業時間
初期/継続応答時間
重大度1
重大度2
重大度3
重大度4
Premium
営業時間（重大度1と2の場合は24時間365日）
初期応答時間
継続応答時間
1営業時間
1時間
1 時間またはお客様との
合意による
4営業時間
2時間
4 時間またはお客様との
合意による
1営業日
4営業時間
8 営業時間またはお客様
との合意による
2営業日
8営業時間
2 営業日またはお客様と
の合意による
Red Hat K.K. All rights reserved.
56
サポート問合せ時に必要な情報
以下の情報をご用意下さい
●
プロダクトID（サブスクリプション番号）または顧客番号
●
会社名、ご担当者様のお名前
●
連絡方法（電話/Web）、（電話でのご連絡をご希望の場合、電話番号）
●
関連する製品名とそのバージョン
●
問題の詳細な説明、重大性レベル(開発/本番環境、業務への影響有無、回避方法有無)
以下の情報があるとスムーズな対応が可能になります
●
sosreport -aの出力
●
問題の再現性の有無および再現手順
●
問題を引き起こす可能性のある修正をシステムに対して行ったかどうか
●
エラーメッセージや自己診断メッセージは表示されるか？される場合は、その内容
●
メッセージの他にエラー番号等は表示されるか？
Red Hat K.K. All rights reserved.
57
サポート窓口
L1-L3製品（Red Hatが直接サポートする製品）
レ 窓口
ッ
ド
ハ 窓口
ッ
ト
サポート
L1-L3製品
L3製品
バックエンドサ
ポート
L1-L3製品
サポート
Ｏ
Ｅ
Ｍ
L3製品
窓口
お
客
様
サポート
OEM 各社によるサポートは、障害発生時の HW/SW の一次切り分け、
HW 特有のドライバ提供などの強みがあります
OEM各社で、SLAやサポート対象項目等のサポート内容が異なる事があります
Red Hat が直接サポートする製品（L1-L3製品）であれば Red Hat サポートセンターが
直接サポートします
58
Red Hat K.K. All rights reserved.
upstream first policy
Red Hat K.K. All rights reserved.
59
upstream firstポリシー
upstreamとは?
●
●
ソフトウェア開発をおこなうプロジェクトを、RHELなどのディストリビューショ
ンでは“upstream”と呼んでいます
linux kernelの開発プロジェクト、firefoxの開発プロジェクト、Apache httpdの開
発プロジェクトなど
RHELへの修正は基本的に“upstream first”ポリシーで作成されます
1. 問題を発見、原因をつきとめる
2. Red Hatのエンジニアがupstreamへ修正案を提案
3. upstreamで議論→検討→修正実施
4. upstreamでの修正をRHELへバックポート
このようにupstreamを先に修正することで、以下を回避します
●
メジャーバージョン変更後に同じ問題が再発すること
●
低品質なバグ修正による追加のトラブル
●
upstreamと非常にかけ離れた状態になること
Red Hat K.K. All rights reserved.
60
