Automation with Ansibleコース(DO407 :4日間)のご紹介

OSSの構成自動化ツールとして人気の Ansible トレーニングコースの提供が開始されました。

5月29日~6月1日のコースは満席間近ですが、新たに7月、8月度の開催日が公開されましたので合わせてご紹介します。

Automation with Ansibleコース(DO407 :4日間)

本コースでは、受講者はハンズオンラボを通じて、Ansibleによる管理対象ホスト上のシステム管理タスクの自動化、Ansible Playbook の作成とタスク実行の標準っか、Playbookの集中管理、そして、Ansible Towerを使用してWebインターフェイスの反復実行をスケジュールする方法を学びます。

また 受講者は Ansible Vaultにより Ansibleの暗号化を管理したり、Ansible Towerをデプロイしたり、それを使用してシステムを管理したり Vagrant とともにDevOps環境でAnsibleを使用する方法についても学びます。

学習内容サマリー

  • 中央集中ノードおよび管理対象ホスト上へのAnsible のインストールおよびトラブルシューティング
  • Ansible を使用した、アドホックコマンドや Playbook の実行タスクの自動化
  • 効率的な Ansible Playbook の作成
  • Ansible Vault による、タスクに必要な暗号化データの保護
  • Ansible Tower の使用によるエンターブライズレベル Ansibleの デプロイ管理
  • DevOps 環境での Ansible と Vagrant との連携

 

コーススケジュール

  • 2017年5月29日~6月1日 会場:品川御殿山会場
  • 2017年7月24日~7月27日 会場:品川御殿山会場
  • 2017年8月14日~8月17日 会場:品川御殿山会場

※6名以上の参加を希望される方は別途ご相談下さい。

日数/時間

4日間 9時30分~17時30分

標準価格(税別)

220,000円~ ※トレーニングの価格詳細はお問い合わせください。

認定試験付きコース:DO408 (5日間:最終日試験)も提供しております。

トレーニングコースの詳細は以下のURLをご確認下さい。
https://www.redhat.com/ja/services/training/do407-automation-ansible

レッドハットトレーニングコースのご購入はサイオステクノロジーまでお気軽にご相談下さい。
https://lp.sios.jp/RH_Inquiry_RH.html

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 パッケージ毎のサポート期限 は以下ページで確認できます

AnsibleとRed Hat Identity Managementを併用すると便利

Ansibleでの管理は便利ですが、Red Hat Identity Managementを利用しているとAnsibleを利用しはじめる時のセットアップ作業がさらに便利になります。

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

Ansibleでの管理は便利ですが、Red Hat Identity Managementを利用しているとAnsibleを利用しはじめる時のセットアップ作業がさらに便利になります。

Ansibleでの管理の前にやること

Ansibleでの管理をはじめる前に行う典型的な準備として以下のようなものがあります。

  1. 管理対象ホストにansibleユーザを作成する
  2. 管理対象ホストでansibleユーザがrootになれるようsudoerを設定する
  3. ansibleホストから管理対象ホストにsshで接続可能にする
  4. インベントリに管理対象ホストを追加する

これらの操作は簡単なものですが、ノードが増えると面倒になってきます。

Identity Managementと一緒にAnsibleを使う

運用環境で Red Hat Identity Management(以下IdM)を利用している場合、これらの準備をほとんど自動にできます。

  1. ansibleユーザはIdMに一回登録しておけばどのホストにも存在
  2. IdMはsudoerの管理もできるので、ansibleユーザがrootになれるポリシーも都度の作成は不要
  3. sshでの接続に必要ansibleホストの公開鍵、管理者のssh公開鍵の配布もIdMが実施。管理者もIdM内のユーザであれば認証はKerberosで完了するのでパスワードによる認証を(一時的にも)許可する必要がない
  4. IdMのAPIを利用して、AnsibleのダイナミックインベントリでIdMに登録されたホストを参照できる https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py

特にsshとの連携は強力で、ansibleを普段実行しないホストから実行したいような場合にも、新しいssh公開鍵をssh-copy-idで配布するのではなくIdMのansibleユーザに登録するだけで利用できます。

Identity Managerを利用する場合に管理対象ホストの設定

適切にIdMを設定できていれば、管理対象ではわずかな操作で上記が実現できます。

ipa-client-installコマンドでドメインに参加します。

# ipa-client-install --domain=EXAMPLE.COM --server=ipa.example.com

これだけで管理対象側の設定作業がおしまいで、ansibleでの接続が可能になります。

参考文献

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パッケージへもアクセスが可能です。

関連資料

RED HAT FORUM 2016 Tokyo The power of participation -アイデアとテクノロジーが生むオープンイノベーションの破壊力-

2016年10月5日にレッドハット株式会社主催の RED HAT FORUM 2016 Tokyo The power of participation -アイデアとテクノロジーが生むオープンイノベーションの破壊力- が開催されます。

本登録の受付が開始されましたので、ぜひご興味の分野のセッションの申し込みをお早めご登録ください。
人気のセッションでは早々に満席となることが想定されています。

お申し込み https://redhatforum.jp/

RED HAT FORUM 2016 Tokyo
The power of participation
-アイデアとテクノロジーが生むオープンイノベーションの破壊力-

レッドハットは、10月5日(水)国内最大級のOSSイベント「レッドハット・フォーラム 2016」を開催いたします。本年のテーマは「The power of participation ―アイデアとテクノロジーが生むオープンイノベーションの破壊力―」。
オープンソースソフトウェアがもたらす価値を、ぜひ会場でご体感ください。

開催概要

日程:2016年10月5日(水)
会場:ウェスティンホテル東京 〒153-8580 東京都目黒区三田1-4-1
主催:レッドハット株式会社
参加費:無料
アクセス:JR山手線・埼京線「恵比寿駅」東口/日比谷線「恵比寿駅」
JR方面出口より 「恵比寿スカイウォーク」で約10分

お申し込み https://redhatforum.jp/

セッション

OpenStack/クラウド、コンテナ/DevOps、アプリケーションプラットフォーム、オートメーション/マネジメント、ビッグデータ/IoT の5つのカテゴリをテーマに、先進的なお客様導入事例やパートナーソリューション、レッドハットの最新テクノロジーの紹介など、30を超えるセッションをご用意しています。ビジネスに生かせる企業IT変革のヒントをぜひ見つけてください。

ミニシアター

展示会場内で展開するミニシアターでは、スポンサー企業各社のソリューションを各15分間でコンパクトにご紹介します。OpenStack や Io T、ビッグデータ、DevOps など今年イチオシのソリューションの最新トレンド・技術情報を、ショートセッションで気軽にご聴講いただけます。ぜひお立ち寄りください。

展示

レッドハットと協賛スポンサーによる最新OSS製品・技術ソリューションを一挙にご覧いただけるパビリオン会場です。会場では、レッドハットのソリューションアーキテクトをはじめ、製品・技術のエキスパートが、その場で直接皆様のご相談にお応えします。各社ブース展示に加え、ミニシアター講演、ネットワーキングパーティなど随時ご参加いただける企画をご用意しています。

Red Hat Enterprise Linuxの互換性維持

Red Hat Enterprise Linuxでは、アプリケーションソフトウェアの互換性について明確なポリシーを定義し、それに従ってアップデートを提供することでお客様がアップデートを適用しやすくなるよう取り組んでいます。

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

オペレーティングシステムをアップデートをする時、アプリケーションソフトウェアの互換性に問題があるとこの互換性をチェックする必要がでてくるためアップデート作業が困難になってしまいます。Red Hat Enterprise Linuxでは、アプリケーションソフトウェアの互換性について明確なポリシーを定義し、それに従ってアップデートを提供することでお客様がアップデートを適用しやすくなるよう取り組んでいます。

メジャーリリース内の互換性

Red Hat Enterprise Linuxの主要な目標の 1 つは、安定した一貫性のあるランタイム環境をサードパーティアプリケーションへ提供することです。これを実現するために、メジャーリリース内で発行される全てのパッケージアップデートに対して、以下の互換性を維持するよう努めています。

  • アプリケーションバイナリの互換性
  • 設定ファイルの互換性
  • データファイルの互換性

たとえば、Red Hat Enterprise Linux 6.1 から Red Hat Enterprise Linux 6.2 へのパッケージアップデートや、特定の脆弱性を修正するパッケージアップデートは、アプリケーションが標準の Application Binary Interface (ABI) を順守している限りにおいて、その機能を破壊することがないように保守されています。このポリシーと取り組みにより、ほとんどの場合は単純にパッケージの更新を実施してアップデートを完了することができます。

残念ながら完璧な互換性を維持してメンテナンスすることは困難であるため、意図せず互換性が破壊されてしまうケースも発生します。この場合には「リグレッション」と呼ばれてバグ扱いとなり、互換性を回復するための修正が行われます。

実際にリグレッションに対する修正は実施されています。カスタマーポータルにて”regression”などのキーワードで検索すると、一時的にリグレッションが発生し、それを修正したという内容の記事をみつけることができます。皆様がご利用のアプリケーションについて、もしアップデートにより動作が変わるような場合にはサポート窓口までご連絡ください。

メジャーリリース間の互換性

メジャーリリースをまだいだ互換性については、”Application Compatibility Guide”内で定義される「コアライブラリ」と互換性を維持するためのライブラリを2バージョンあとのメジャーリリースまで提供します。

たとえば、Red Hat Enterprise Linux 7のコアライブラリであるlibxml2とlibcを利用したプログラムを作成するとします。将来出荷される “RHEL 8” や “RHEL 9” では異なるバージョンのlibxmlやlibcが採用されるかもしれませんが、その場合であってもRHEL7と互換性を維持するためのライブラリパッケージが提供され、ひきつづき利用することができ、メンテナンスも提供されつづけます。

コアライブラリ以外のライブラリについては、メジャーバージョンが変わったあとの互換性について保証されません。バイナリ形式でソフトウェアを配布したい場合の推奨方式については”Application Compatibility Guide”にまとまっていますのでこちらをご確認ください。

 

関連リンク