Red Hat Enterprise Linux

ホネまでしゃぶろう、Red Hatサポート

Red Hatのサポート窓口では幅広いサービスを提供しています。今回はサポート窓口で提供しているサービスのうち、あまり知られていなさそうなものをピックアップして紹介します。

レッドハットの森若です。

今回はRed Hatのサポート窓口が提供するサービスのうち、あまり知られていなさそうなものをとりあげて紹介していきます。

システムのライフサイクルとサポート

システムのライフサイクルと、それぞれのフェーズにマッチするサポートのサービスをまとめたのが以下の図です。

 

レッドハット製品のサブスクリプションにはインシデント件数無制限の問いあわせ対応が含まれています。ここで何を問いあわせることが可能なのか、あまり意識していない方も多いかなと思います。

「Red Hatのプログラムに問題か問題らしい何かがあって、その対応が必要なときにバグレポートとか質問できるだけでしょ?」と思われているかもしれません。しかし問題が発生した時以外にもサポート窓口を活用することができます。

 

やりたいことができるか?の質問

新しいシステムを設計する際に、はじめて使うソフトウェアなどについて「自分がやりたいことが製品の範囲でできるのか、できるとするとどうやったらできるのか?」ということが気になります。このような時にもサポートへ問いあわせることができます。

たとえば以下のような質問に対応できます

  • 「Apache httpdでwebサーバを構築して、あるタイミングで現在どれだけ接続されているのかを測定したい。そういうことってできますか?どうしたらいいでしょうか?」
  • 「RHEL7.4のsambaでは xx という機能が有効になっていますか、それとも無効ですか?無効だとしたら同じようなことを実現する他の方法はありますか?」

 

アーキテクチャレビュー

いくつかの構築が難しい製品について「アーキテクチャレビュー」と呼ばれるプロセスが定義されています。サポート窓口でアーキテクチャレビューを申し込むことで、お客様が構築しようとしている、または構築したアーキテクチャのレビューをおこないます。

アーキテクチャレビューは以下を目的としています:

  • 適切に動作しないことがわかっている構成や設定についての指摘と排除
  • パフォーマンス上の問題につながる、注意するべき点の指摘
  • お客様の構成のうち、サポートされる範囲とサポートできない範囲を明確にする

アーキテクチャレビューにSLAは適用されません。「x月x日までに完了します」というようなお約束ができない点にご注意ください。

以下に各製品のアーキテクチャレビューについてナレッジベースエントリのリンクを記載します。必要な情報や制限などが記載されています。

 

プロアクティブチケット

ユーザへの影響を少なくするため、土日や深夜にアップデートなどの作業を行うことがあります。対応するPremiumサブスクリプションを購入している場合、休日や夜間であっても(重要度により)サポート窓口で問い合わせを受けつけることができます。しかしいざ問題が発生してからケースを作成し、システムの構成、作業内容、各システムのsosreport取得と登録、障害内容などを記載するとどうしても時間がかかってしまいます。

プロアクティブチケットはこのような場合に便利な仕組みで、Premiumサブスクリプションを所有していてケースのやりとりが英語で可能な場合、作業前にサポートケースを開いておくことができます。あらかじめ情報を共有し、担当サポートエンジニアが対応の準備をしておくことで実際に問題がおきた場合の初動を早くすることができる仕組みです。

プロアクティブチケットは通常のWebでの問いあわせと同じ窓口で、以下のように登録します。

  • 4営業日以上前にケースを作成
  • タイトルの先頭にProactiveとつけてケースを作成(重大度は3)
    • 例:  [PROACTIVE] – RHEL 7 kernel update
  • システムの現状および、予定されている作業についてできるだけ詳細を記載
    • 日程・イベント予定
    • 現状システムのsosreport
    • お客様の連絡先

プロアクティブチケットについては以下のナレッジをご確認ください https://access.redhat.com/node/286633

 

まとめ

今回はRed Hatのサポート窓口で提供されている、あまり知られていないサービス3種類をご紹介しました。

「Red Hatの製品はがっつり使っていて、サポートにもよく質問するよ」という方でも知らなかったものがあるかと思います。ご活用ください。

パフォーマンスチューニングを自動化するtuned

Red Hat Enterprise Linuxの6.0から、パフォーマンスチューニングに必要な設定をまとめておこなう tuned が同梱されています。今回はこのtunedをご紹介します。

レッドハットの森若です。

Red Hat Enterprise Linux のパフォーマンスチューニングを行いたい場合「どんな場合でも利用できるある1つの設定」というものはありません。たとえば以下のようなケースが考えられ、これらはそれぞれ異なる設定をおこなうことになります。

  • 計算スループットが重要で、イベントに対するレイテンシはあまり重要ではない場合
  • 省電力が重要なノートPCでのデスクトップ用途の場合
  • ネットワークのレイテンシを重視する場合

今回はこれらのパフォーマンスチューニング設定を簡易に行うための仕組みである tuned を紹介します。

tuned

tunedはRHEL 6.0から導入されたデーモンで、IOエレベータの設定、メモリ管理の設定、CPUスケジューラの設定、CPUの省電力設定、キャッシュのパラメータなどの各種設定をまとめたものを「プロファイル」として定義し、まとめて設定します。さらに仕組みを提供するだけでなく、典型的ないくつかのプロファイルを同梱しています。

このtunedを活用することで、典型的なケースについては非常に簡単にパフォーマンスチューニングを行うことができます。

tunedのプロファイル

早速tunedに添付されるプロファイルを見てみましょう。RHEL Server 7.4 で以下のようにコマンド 「tuned-adm list」により利用可能なプロファイルと現在設定されているプロファイルが表示されます。

# tuned-adm  list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optimize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest

それぞれのプロファイルについては man 7 tuned-profiles に概要が記載されていますが、 /usr/lib/tuned/プロファイル名/tuned.conf に設定が含まれていますので詳細はこれらのファイルを参照するのが手早いです。

表示ではわかりませんが balanced, latency-performance, throughput-performance, powersave の4種類が基本的な(方針の違う)プロファイルとして定義されており、その他のプロファイルはこれらを継承して少し変更する形で実装されています。

プロファイルの指定

tunedのプロファイル指定は、 「tuned-adm profile プロファイル名」で行います。指定すると即座に反映され、その後は再起動してもtuned起動時にプロファイルが適用されます。何もしていなければデフォルトでtunedは有効で起動されます。

現在有効なプロファイルを確認するには、 「tuned-adm active」とすると表示されます。同じものが「tuned-adm list」の最終行にも出力されます。

# tuned-adm profile latency-performance
# tuned-adm active
Current active profile: latency-performance

カスタムプロファイル作成時のヒント

独自にプロファイルを作成する場合は  /etc/tuned/プロファイル名/tuned.conf に必要な設定を記載することになります。include文にて既存のプロファイルをベースとすることもできます。

組織内で標準的に利用するtunedプロファイルを必要なパターンにあわせて定義しておけば、ファイルを数個設置してtuned-admで指定するだけで作業が完了しますので、初期設定作業が大幅に簡素化できます。

tuned.conf内で扱える設定は多岐に渡り、sysctlの指定、sysfsへの指定、ethtoolの指定、各種周辺装置の省電力設定、linux kernelの起動オプション(反映には再起動が必要)などがあります。さらにプロファイル適用時と適用終了時に実行するスクリプトも指定できますので、多くの場合はtunedのプロファイル内にパフォーマンスチューニング設定を集約することができます。

関連ドキュメント

継続的な学習を実現する Red Hat Learning Subscription

エンジニアの技術力の向上には継続的な学習が必要です。Red Hat公式トレーニングの全コースをいつでも学習できるRed Hat Learning Subscriptionをご紹介します。

レッドハットの森若です。

次々と新しい技術や製品が登場する昨今、エンジニアは継続的な学習が必須となっています。みなさまはどのようにして新しい技術を獲得しているでしょうか? 今回はレッドハットが提供する Red Hat Learning Subscription をご紹介します。

トレーニングの必要性

社内の技術力を高めて事業へ貢献するためには、継続的な学習が必要です。たとえばコンテナによるアプリケーションの配備のような新しい技術をキャッチアップすることでインフラの選択肢を増やす、現在利用している技術へより深い理解を得ることで障害時の障害解析をスムーズにする、AnsibleのPlaybookを書けるようになって日常業務の自動化を行うなど、多くのシーンで様々な技術を習得する必要があります。

トレーニングをするときの課題

トレーニングに必要なものは何でしょうか?

学習のための環境

たとえばAnsibleの学習をする際、Ansibleが動作するマシン、管理されるマシン1台(できれば2台)の合計2台あるとできそうです。OpenStackではどうでしょう。コントローラに3台、Directorに1台、コンピュートに2台、さらに共有ストレージ役のNFSサーバで計7台くらいでしょうか……?

これから学習しようという場合、必要台数や条件がよくわからないこともありますし、利用できるリソースが限られていることも多いでしょう。またたとえば1ヶ月学習のために時間がとれても、最初の2週間ほどが基本的な環境構築に費されるということもよくあります。

エンジニアの時間

レッドハットの公式トレーニングでは、コースによっては教室で4日間のハンズオントレーニングを行っています。連続して学習に集中できる環境は非常に学習効果が高いですが、「4日間連続してスケジュールを押さえる」こと自体が難しい場合も多いです。

信頼できる資料

多くのソフトウェアについて、簡単な紹介や「やってみた」というblog記事などはインターネットにあふれていますが、わずかな例外を除けば、ある技術を身につけるために使える信頼できる資料というものは滅多にみつからないものです。たとえば「AnsibleのPlaybookを書けるようになりたい」というときに公式マニュアル以上の、説明・例題・演習を含めたテキストが見つかるでしょうか?

Red Hat Learning Subscription

Red Hat Learning Subscription とは、オンラインで利用できるサブスクリプション制のトレーニングです。1年間有効なサブスクリプションとして販売され、期間中はレッドハット公式トレーニングの全コース(現在44コース)を好きなタイミングで受講することができます。
日本の教室トレーニングで実施されているもののほとんど(12コース)はテキストが和訳されています。また日本で実施されていないコース(32コース)も英語で受講できます。

さきほど挙げた3つの点について見てみましょう

学習のための環境

各コースにはコース内容にあわせたラボ環境があらかじめ用意されており、オンデマンドで5分程度で利用できるようになります。このラボ環境は年間400時間利用可能なので、単純計算で平均毎週8時間ずつ演習ができます。

 

エンジニアの時間

24時間365日いつでもアクセスできますので、隙間時間での受講が可能です。スマートホンなどからも接続できるため、通勤電車でテキストを読んだり、テキストをタブレットで表示しながらラボをPCで実施するなども可能です。

信頼できる資料

15年以上の実績があり高い評価を受けているレッドハットの教材がそのまま利用できます。トレーニングの資料はレッドハットが継続的にメンテナンスしています。テキストやラボに技術的な問題がある場合、英語に限定されますがサポート窓口を利用できます。

さらにRed Hat Learning Subscriptionでは、コースを横断した全文検索が利用できます。コマンド例のコピー&ペーストなども簡単にできますので紙の資料より便利かもしれません。

まとめ

継続的な学習のために必要な各種の特長をもつ Red Hat Learning Subscription をご紹介しました。もしご興味があれば sales-jp@redhat.com までご相談ください!

関連資料

Red Hat Enterprise Linux 7.4 public betaがでました

Red Hat Enterprise Linux 7.4のPublic betaが出荷されました。Public betaを試すときに気になるポイントをまとめました。

レッドハットの森若です。

2017年5月24日にRed Hat Enterprise Linux 7.4のPublic betaが出荷されました。Public betaを試すときに必要な情報をまとめました。

Public Betaとは

Red Hat Enterprise Linux 7.3は2016年11月3日に出荷されました。そのため現時点でおよそ半年経過しています。Public betaは機能追加などがひととおり終わり、ある程度社内でのテストを行ったものが公開されています。Public beta出荷から通常さらに2〜3ヶ月ほどテストおよび修正をおこなったのち製品版が出荷されます。

Public betaは何かRed Hat製品を持っている人であれば誰でも入手でき、追加のサブスクリプション費用は不要です。試していて何か問題をみつけた場合、サポート窓口までお報せください。最終製品の改善に役立ちます。

注意点としては、Beta版から製品版へのアップデートはできませんので、将来出荷されるRHEL 7.4のシステムを構築するなどの目的には利用できません。

Public Betaの入手

ではPublic betaを入手してみましょう。

カスタマーポータルのダウンロードページへ行きます。評価版やDeveloper Programでもよいですが、何かしらのサブスクリプションを持っているアカウントが必要です。

https://access.redhat.com/downloads/content/69/ver=/rhel—7/7.4%20Beta/x86_64/product-software

アップデート内容は?

さて、RHEL7.4 ではどのような変更がやってくるのでしょうか? Public betaにはリリースノートがありますので、そちらを確認することで主要な変更点を確認できます。このリリースノートはまだ抜け洩れがある状態で公開され、製品リリース直前まで随時更新されます。ここに記載されているものが変更点の全てとは言えない点にご注意ください。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.4_Release_Notes/index.html

RHEL7.4 public betaのリリースノートを読んで私が個人的に気になった新機能やバグフィックスについて、以下でまとめています: https://togetter.com/li/1113512

問題があったら?

Public betaはサポートの対象ではありませんが、バグレポート、障害レポート等は受け付けています。

パフォーマンスの劣化、今まで動作していたソフトウェアが動作しないなどの非互換など、怪しい動作があればぜひサポート窓口までお報せください。

RHELで新しいgitやPython3を使うには?

現在のRed Hat Enterprise Linux 7ではgitのバージョンは1.8.3です。「もっと新しいバージョンのgitが使いたい!」という方も多いかと思います。このような場合に利用できる Red Hat Software Collectionsをご紹介します。

Red Hat Software Collections

RHEL上でソフトウェア開発をおこなう時に、 「Red Hat Enterprise Linuxに含まれるバージョンが古くて都合が悪い」ということは往々にして発生します。たとえばRHEL 7にはまだPython 3.xは含まれていませんし、gccのバージョンも4.8です。

このような場合に役にたつのがRed Hat Software Collectionsで、RHELのライフサイクルとは独立したライフサイクルでRHEL上で利用できる追加のソフトウェア群を提供します。これはRHELとは異なり最大3年(一部2年)のサポート期間ですが比較的最近のソフトウェアを利用できること、RHELの既存パッケージと競合しないよう工夫してパッケージされていることが特徴です。

Red Hat Software Collectionsについては2年ほど前に「Red Hat Software Collections 2.0 とは」という記事でもご紹介しているのですが、この2年の間に2.1, 2.2, 2.3とバージョンが新しくなってきたのであらためてご紹介します。

Red Hat Software Collections 2.3

Red Hat Software Collections 2.3 ではあたらしく以下のソフトウェアが提供されます。

  • Red Hat Developer Toolset 6.0
    • GCC 6.2.1
    • binutils 2.27
    • elfutils 0.167
    • GDB 7.12
    • strace 4.12
    • SystemTap 3.0
    • Valgrind 3.12.0
    • Dyninst 9.2.0
  • Eclipse 4.6.1
  • Git 2.9.3
  • Redis 3.2.4
  • Perl 5.24.0
  • PHP 5.6.25
  • PHP 7.0.10
  • Python 3.5.1
  • MongoDB 3.2.10
  • MySQL 5.7.16
  • Ruby 2.3.1
  • Thermostat 1.6.4
  • Common Java Packages 1.1

 

完全な一覧表はこちらで確認できます。 https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.3_Release_Notes/chap-RHSCL.html#tabl-RHSCL-Components-all

RHSCL 2.0 サポート期限のご注意

過去にRed Hat Software Collections 2.0をご利用の方は、Developer Toolset 4についてはあと半年ほど、それ以外のパッケージをご利用の場合はあと1年ほどでサポートが終了します。この機会にご利用のパッケージをご確認ください。

Red Hat Software Collections パッケージ毎のサポート期限 は以下ページで確認できます

Red Hat Enterprise Linuxを仮想化環境で動作させる時の注意点

Red Hat Enterprise Linuxを仮想化環境で動かすことが多くなっています。認定済みの環境一覧や認定外の環境での注意点、サブスクリプション管理用のvirt-whoデーモンについてご紹介します。

 

レッドハットの森若です。Red Hat Enterprise Linuxを仮想化環境で動かすことが多くなっています。物理サーバー単位で仮想マシンを作り放題のサブスクリプション製品がありますので、ご活用いただくシーンも増えています。

RHELで認定済みの仮想化環境や認定外の環境での注意点、サブスクリプション管理用のvirt-whoデーモンについてご紹介します。

無制限ゲストOS製品

レッドハットのサブスクリプション製品の中には、あるサーバー上で仮想マシンをいくつでも作成できる製品があります。主に以下の3種類の製品です(その他の製品とのセットなどもあるのでこの他にも存在します)。これらの製品は物理サーバのソケットペア(1つまたは2つのCPUソケットで、サーバ筐体をまたがない)毎に購入します。

  • Red Hat Enterprise Linux for Virtual Datacenters (仮想化環境はなしで、ゲストOSのみ)
  • Red Hat Enterprise Linux OpenStack Platform (OpenStack環境と無制限ゲストOSのセット)
  • Red Hat Enterprise Linux with Smart Virtualization (RHEV仮想化環境とゲストOSのセット)

サポート対象の仮想化製品

Red Hat Enterprise Linuxの動作が認定されている仮想化製品は以下に一覧が提供されています。

https://access.redhat.com/certified-hypervisors

virt-who

無制限ゲストOS製品を利用する時には、仮想マシンにインストールしたRed Hat Enterprise Linuxを登録するだけでなく、それぞれが動作しているハイパーバイザをサブスクリプション管理に登録することで適切に更新などが可能になります。

サブスクリプション管理の仕組みとして利用可能な仕組みとしては、カスタマーポータル、Red Hat Subscription Asset Manager、Red Hat Satelliteの3種類があります。

これらに対して「どのハイパーバイザでどの仮想マシンが動作しているか」という対応関係を知らせるために利用するのがvirt-whoデーモンです。virt-whoデーモンはRHELがサポートする仮想化環境である以下の4種類の仮想化環境に対応しています。

  • RHEL KVM
  • RHEV
  • VMware ESX, VMware ESXi
  • Microsoft HyperV

古いバージョンでは一部の環境への対応ができていないものがあります。詳しくは https://access.redhat.com/ja/articles/1283963 をごらんください。

 

virt-whoの使い方

それぞれの仮想化ホスト上に1つRHEL仮想マシンを用意のうえvirt-whoを実行し(RHEV-M または vCenterへ接続する場合にはクラスタ全体で1つあれば十分です)て、それぞれのホストを登録します。virt-whoデーモンの設定はファイル /etc/sysconfig/virt-who におこないます。仮想化環境の種類と、サブスクリプション管理の仕組みを指定します。

関連するナレッジベースの記事を以下に記載します。最初の「RHEL サブスクリプション (2013 パッケージ) の使用: シナリオ 5 仮想データセンター」に概要が記載されていますので、まずこの記事を確認してから各環境ごとのナレッジベースを確認するとわかりやすいです。

VMware環境上でのRed Hat Enterprise Linux 7.2以前から7.3へアップデート時の注意点と、その解説

2016年11月3日にリリースされたRHEL 7.3ではアップデートに関連した比較的大きな問題がありました。本記事では問題の概要と背景をご紹介します。

レッドハットの森若です。2016年11月3日にリリースされたRHEL 7.3ではアップデートに関連した比較的大きな問題がありました。概要は以下のようなものです。

——————————————————————————–

問題:
VMware環境上で動作している Red Hat Enterprise Linux 7.2以前の環境を、7.3へアップデートするとインタフェース名が変わり、再起動時にネットワークのセットアップに失敗する場合があります。

解決策1:
RHEL 7.3に更新したあと再起動せずに、systemdパッケージを systemd-219-30.el7_3.6 以降のバージョンへ更新します。「RHEL 7.3に更新したあと再起動して問題が発生した」事後には、systemdパッケージのアップデートは効果がありません。

解決策2:
既に問題が発生した場合、ネットワーク設定を変更する必要があります。詳しい手順はナレッジベース内「RHEL 7.3 にアップデートした後にインターフェイス名が変更になり、ネットワークが起動しない」https://access.redhat.com/ja/solutions/2756581 をご確認ください。

※ ISOイメージによる更新の場合には現在でもこの問題が発生します。

——————————————————————————–

さて今回はこの問題の背景を見ていきます。

systemdによる予測可能なNetwork Interfaceの命名

systemdはハードウェアの接続情報を元に一貫したNetwork Interfaceへの命名を行っています。たとえば「eno1」のような名前がつき、Ethernet(en)のオンボード(o)で1ポート目(1)のような名前がつきます。このような構成情報はファームウェアから提供されており、dmidecodeコマンドでも確認することができます。

Handle 0x001E, DMI type 41, 11 bytes
Onboard Device
        Reference Designation:  Onboard LAN
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:00:19.0

VMware環境でのインスタンス番号

この番号について、VMware環境のファームウェアは異常に大きなインスタンス番号を報告します。1600万番前後の数になります。RHELの7.0から7.2までは、この番号を素直に利用した eno16780032 のようなNetwork Interface名を命名していました。

LinuxでのNetwork Interface名前長制限

ところがこの命名には、単純に長くて入力が面倒という以上の問題があります。Linuxには「Network Interfaceの名前は15文字まで」という制限があります。eno+数字8桁で11文字利用しているので、残りは4文字しか利用できません。たとえばこの時VLAN tag ID として1000を利用するためのインタフェースを作成しようとすると、”eno16780032.1000” のようになってほしいところですが、”eno16780032.100”となってVLAN tag IDとして100や1005を使うインタフェースと名前が衝突してしまいます。

systemdが採用したワークアラウンド

RHEL 7.3のsystemdでは、この問題に対するワークアラウンドとして、オンボードのNICで16384番より大きい番号が与えられた場合はスロット番号またはバス番号を元にした名前を付与するよう変更されました。

udevadmでNetwork Interfaceの情報を見てみると、ID_NET_NAME_ ではじまるエントリが複数あることがわかります。

# udevadm info /sys/class/net/eno16780032
P:/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/eno16780032
E:DEVPATH=/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/eno16780032
E:ID_BUS=pci
E:ID_MODEL_FROM_DATABASE=VMXNET3 Ethernet Controller
E:ID_MODEL_ID=0x07b0
E:ID_NET_DRIVER=vmxnet3
E:ID_NET_LABEL_ONBOARD=enEthernet0
E:ID_NET_NAME_MAC=enx005056a570ba
E:ID_NET_NAME_ONBOARD=eno16780032
E:ID_NET_NAME_PATH=enp11s0
E:ID_NET_NAME_SLOT=ens192
E:ID_OUI_FROM_DATABASE=VMware, Inc.
E:ID_PATH=pci-0000:0b:00.0
E:ID_PATH_TAG=pci-0000_0b_00_0
E:ID_PCI_CLASS_FROM_DATABASE=Network controller
E:ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E:ID_VENDOR_FROM_DATABASE=VMware
E:ID_VENDOR_ID=0x15ad
E:IFINDEX=2
E:INTERFACE=eno16780032
E:SUBSYSTEM=net
E:SYSTEMD_ALIAS=/sys/subsystem/net/devices/eno16780032
E:TAGS=:systemd:
E:USEC_INITIALIZED=28864

NetworkManagerのconnection識別方式

NetworkManagerでネットワークを初期化する際には、設定にNetwork Interface名とMACアドレスが含まれていると、MACアドレスにあわせて指定された名前にリネームして初期化を行います。しかしMACアドレスが含まれない場合はNetwork Interface名が一致しなければ初期化がおこなわれません。

このため、NetworkManagerによる設定を利用しており、RHEL 7.0から7.2まででNetwork Interfaceを設定したのち、MACアドレスの設定を含まないよう設定し、7.3へアップグレードして設定を修正せずに再起動すると初期化に失敗します。

systemd-219-30.el7_3.6で導入されたワークアラウンド

この問題は出荷翌日の11月4日に発見され、ワークアラウンドを含んだ systemd-219-30.el7_3.6 が11月9日に出荷されました。この中で利用されているワークアラウンドは、systemdパッケージ更新時に以下のような内容のスクリプトを実行することにより対応しています。

もしこの問題の影響をうける(enoではじまり16378より大きな数で終わる名前の)インタフェースがある場合、udevのルールに「現在のMACアドレスを持つ場合に現在と同じインタフェース名に名前をつけかえる」というエントリを追加します。

これにより、影響をうけるアップデートの場合にのみインタフェースの名前を維持する対策が行われます。注意点として、この状態の仮想マシンをクローンするなどでMACアドレスが変更されるとインタフェース名が新しいポリシーによるものに変わります。

Red Hat Satellite 6でerrataを適用してみる

Red Hat Satelliteの利用デモです。

レッドハットの森若です。今回はいつもと趣向を変えて、Red Hat Satelliteを使う手順を見てみましょう。

Red Hat Satelliteでは管理対象ホストを「コンテンツホスト」というページで一覧することができます。この中で、(1)各ホスト毎にセキュリティfix, バグfix, 機能拡張のerrata数を確認することができます。(2)ホスト名をクリックすることで、各ホストの詳細を確認する画面に切り替わります。

この画面ではサブスクリプションの状態確認・管理や、パッケージの追加・削除などの操作が行えます。ある特定1台のホストを管理する場合には主にこの画面の中で操作をおこなうことになります。

「一括処理」のボタンを押すことで複数ホストをまとめて処理します。選択した1つ以上のホストについてまとめて操作ができます。今回は「エラータ」タブを選択して、RHELの既存の修正を適用してみます。

更新対象としたいホストを選択のうえ(3)適用したいアドバイザリ(この例ではRHSA-2016:1633)を選択して、(4)「選択をインストール」をクリックします。ボタンの横のプルダウンメニューから、Red Hat Satelliteのエージェントを利用した方法とsshでのリモートコマンド実行を選択できます。

sshによる実行の場合、時刻を指定した実行の指定が可能です。

処理の実行を開始すると、(6)タスクの進行状態が表示されます。タスク管理はバックグラウンドで動作しているので、このまま他の処理をはじめたり、ブラウザを閉じてしまってもかまいません。

しばらく待つと処理が完了し、以下のようにタスクの実行状態が”success” というように更新されます。

複数ホストに対する処理では、各ホスト毎にサブタスクが定義され、一部のタスクで問題が発生してもその他のタスクは引き続き更新処理が継続されます。タスクの実行結果はSatelliteに蓄積されているので後からどのタスクが失敗したかを確認することもできます。

この例ではRHEL 1台に対しての更新指示でしたが、Red Hat Satelliteではあらかじめ定義したグループを利用したり、各ホストを任意に選択して一時的なグループを作成してアップデートの指示が可能です。

関連ドキュメント

RHEL4の延長サポートおよびRHEL5の通常サポート終了

2017年3月31日にRHEL4の延長サポートとRHEL5の通常サポートが終了します。 そのまま利用しつづけると大きなリスクをかかえることになるので対策をおこないましょう。

レッドハットの森若です。2017年3月31日にRHEL4の延長サポートとRHEL5の通常サポートが終了します。
既存のRHEL4やRHEL5をそのまま利用しつづけると大きなリスクをかかえることになるので対策をおこないましょう。

RHELのライフサイクルとELS add-on

通常のRHELサブスクリプションを買っていると、サポートポリシーに従って各メジャーバージョン(RHEL5, RHEL6, RHEL7)の出荷時点から10年間にわたって修正の提供を受けることができます。その後は新規の調査はおこなわれず既存ナレッジをもとにしたWebおよび電話での問い合わせ対応と既存パッケージの入手だけが可能な ELP (Extended Lifecycle Phase)とよばれる期間にはいります。ELP開始は事実上のサポート終了であり、ELP期間の利用継続は禁止こそされていないものの全く勧められません。

RHELを利用する場合にはこのライフサイクルを確認して、システムにサポートが提供されるようにメジャーバージョンの乗り換えも含めて計画をしていくことが必要です。たとえば2016年10月にシステムを新規に構築して5年間利用する場合、RHEL7で構築して5年間利用するパターンや、RHEL6で3年ほど利用したのちにRHEL7に乗りかえるようなパターンが考えられます。

ELS add-on は、RHEL4とRHEL 5について、パッケージの修正が提供される期間を延長します。ELSは通常のサポートよりも制限が厳しく、サポート対象となるアーキテクチャやパッケージの種類が限定されます。またRHEL 6以降についてはELSは計画されていません。

Red Hat Enterprise Linux のライフサイクルやサポートのポリシーについては以下のページをご確認ください:

利用しているバージョン別の対応方法

基本的には新しい修正が提供されているバージョンへの移行が解決策となります。

RHEL4およびそのELSを利用している場合、2017年3月31日にRHEL4の延長サポートが終了します。サブスクリプションを買って利用を継続することは禁止されてはいませんが、ELSが終了したあとはRHEL4むけには修正が一切出荷されません。できる限り早くの移行が推奨されます。

RHEL5を利用している場合、2017年3月31日に通常サポートが終了します。新しいシステムへの移行が推奨されますが、前述のELSがサポート終了日から利用できますのでシステムを2020年11月までに利用終了することがわかっている場合はELSで提供される更新を適用しつつそのまま利用を継続することも考えられます。RHEL7などの別バージョンに移行する場合にもELS期間の範囲内で移行時期を調整できます。

移行サービスを提供するパートナー

お客様のRHEL4や5からの移行にあたってはレッドハットのパートナーまでご相談ください。以下のキャンペーンサイトからご確認いただけます。

http://jp-redhat.com/rhel4-eol/

関連リンク

ELS? EUS? RHELの延長サポート製品について知ろう

Red Hat Enterprise Linuxはメジャーリリースについては通常7年または10年間、アップデートリリースに対しては最新版のみに対して修正を出荷しています。今回はこのポリシーを拡張する製品、ELSおよびEUSについて見てみましょう。

レッドハットの森若です。今回はRHELの延長サポート製品についてご紹介します。

Red Hat Enterprise Linuxのリリース

RHELのサポート期限について説明する前に、リリースについて簡単に紹介します。2種類のリリースがあります。

  • メジャーリリース (RHEL X)

例: RHEL4, RHEL5, RHEL6

変更点: 基本的に別の製品(アップグレードは可能)

頻度: およそ3年に1回メジャーリリースを出荷する

  • アップデートリリース (RHEL X.Y) (マイナーリリースとも言う)

例: RHEL5.11, RHEL6.7, RHEL7.1

変更点: 新規パッケージの追加や機能拡張を含む。基本的に互換を維持する。

頻度: およそ6ヶ月から8ヶ月に1回アップデートリリースを出荷する

メジャーリリースが出荷されてから、RHEL4では7年、RHEL5以降では10年の間、修正が提供されます。この期間内でProduction 1,2,3 と徐々にフェーズを変えておりポリシーに従って提供する修正の範囲を徐々に狭めています Production 3終了後は、既存ナレッジを元にした電話およびWebでの問い合わせ対応は受けつけるものの新規に修正を提供しないExtended Life cycle Phase(ELP)期間がはじまります。ELPの終了時期は未定です。

メジャーリリースのサポート延長 ELS

このメジャーリリースについて、修正提供をする期間を延長するのがExtended Lifecycle Support(ELS)です。これはアドオン製品で、基本的にProduction3終了後に3年間提供されます。

影響度「重大」のセキュリティー修正と優先度「緊急」の一部のバグ修正が提供されますが、ハードウェア対応または根本原因の分析などは提供されず、サポート対象はインストール済みの既存システムに限定されます。 基本的にはELSは諸処の都合でどうしてもシステム更新ができない場合のための緊急避難です。通常の運用計画ではProduction 3までの期間内での利用をお勧めします。

ELSは通常のサポートと比べると制限が厳しく、サポートされるパッケージやアーキテクチャが限定されています。RHEL3,4についてはサポート対象外となるパッケージが決まっていますRHEL5についてはELSの出荷自体は発表されましたが、パッケージなどは未定です。

通常のアップデートリリースへの修正提供

通常のRHELでは、新しいアップデートリリースが出荷されると今までのアップデートリリースへの修正の提供は終了します。

たとえばRHEL6.7が出荷されると、RHEL6.6までのバージョン用の修正は出荷されなくなります。利用することそのものや、質問対応は問題ありま せんが、修正による対応ができないため「どうしてもRHEL6.5である必要があるけれど、RHEL6.7で修正された問題Xにも対応したい」というよう な場合にはうまい解決策がありませんでした。

Red Hatの対応のようすをあらわしたのが下の図です。RHEL6.0が出荷されたあとRed Hatのエンジニアリング部門が問題を修正します。6.0はサポート期間中なのでバックポートと呼ばれる修正の移植をおこなって出荷します。同時にQA中 で出荷前の6.1にも修正をとりこみます。このようにして現在サポート対象のバージョンと、今後出荷されていくバージョンのどちらでも不具合が修正されて いるように維持していきます。

アップデートリリースのサポート延長 EUS

アップデートリリースに対して「出荷されてから24ヶ月」修正提供を維持するのがExtended Update Support(EUS)です。これはアドオン製品なのですが、24時間365日のプレミアム製品にはEUSが同梱されるように2013年の購入ポリシー 改訂時に変更されました。現在は過渡期なので購入のタイミングや型番によってプレミアムでもEUSが利用できるケースと利用できないケースが混在していま す。

EUSを利用して「アップデート実施回数の削減」が可能になります。

EUSは特定のアップデートリリースにのみ出荷されます。RHEL5であれば「5.2、5.3、5.4、5.6、5.9」に提供されていました。RHEL6では、Production 1期間中のアップデートリリースと決められており、EUSが提供されるのは6.7までのアップデートリリースで、2016年出荷見込みのRHEL6.8からはEUS提供がありません。

延長された期間について、「重大」および一部の「重要」に分類されるセキュリティ問題またはお客様へのインパクトが大きなバグの修正が提供されます。

EUSでカバーされるパッケージのリストが以下に記載されています。

http://www.redhat.com/en/about/redhatenterpriselinuxextendedupdatesupporteuspackageinclusionlist

EUS期間のRed Hatの対応のようすをあらわしたのが下の図です。RHEL6.3サポート期間中に重大な問題が修正された例ですと、EUS期間中であるRHEL6.1 EUS, RHEL6.2 EUSに対して修正をバックポートし、提供します。

 

過去のEUSパッケージへのアクセス

何らかの事情で、過去にEUSご購入のお客様向けに提供されたパッケージが必要なケースがあるかもしれません。このような場合、EUSアドオンを購入すると過去のEUSパッケージへもアクセスが可能です。

関連資料