第9回「アップデートノススメ」
Tweet
今回は、ソフトウェアのアップデートについての基礎知識について紹介します。
RHEL の基礎知識
RHEL とはソフトウェアの名前ではなく、ディストリビューションの名前です。
ディストリビューションとは、無数にあるソフトウェアの中から、当該ディストリビューションのサポート方針に従って選定されたソフトウェアのコレクションです。 RHEL のサポート方針については以下のページを参照ください。
殆どのソフトウェアにはメジャーバージョンとマイナーバージョンという区別があり、メジャーバージョンアップでは新機能の追加など大きな変更が生じるのに対し、マイナーバージョンアップではセキュリティ問題の修正や不具合修正など小さな変更のみが生じるという傾向があります。
RHEL に含まれるソフトウェアは、それぞれに個別のバージョンを持っています。RHEL のマイナーバージョンとは、ある時点において、 RHEL に含まれている特定バージョンのソフトウェアのコレクションを指す名前です。
RHEL のメジャーバージョンが同じであれば、含まれているソフトウェアの種類は同じです。そのため、例えば RHEL6.5 に含まれているソフトウェアを全て RHEL6.6 相当にアップデートすれば、 RHEL のバージョンも自動的に RHEL6.6 にアップデートされます。
RHEL のメジャーバージョンが異なれば、含まれているソフトウェアの種類も異なります。そのため、例えば RHEL5 から RHEL6 へアップデートする場合、RHEL5 に含まれるソフトウェアを個別にアップデートする方法では対応できませんので、 RHEL6 を用いて再インストールを行う必要があります。
RHEL バージョンの詳細については以下のページを参照ください。
ソフトウェア管理の基礎知識
ソフトウェアはパッケージという単位で管理されることが多く、 RHEL では rpm パッケージという形式を採用しています。
ソフトウェアの不具合が見つかった場合は、当該ソフトウェアのサポートを行っている窓口に修正を依頼します。例えば RHEL に同梱されている rpm パッケージの場合には、 Red Hat 社に依頼することになります。
rpm パッケージの場合、修正結果は（修正した差分のみを含む）「パッチ」という単位ではなく「（1つ以上のパッチを適用した）新しいバージョンのパッケージ」という単位で提供されます。例えば「 foo-1.0-1 というパッケージ」を使用している場合には、「 foo-1.0-1 に対するパッチ」としてではなく「 foo-1.0-2 あるいはfoo-1.1-1 というパッケージ」として提供されますので、不具合が修正されたバージョンを使用するためには foo-1.0-1 から foo-1.0-2 あるいは foo-1.1-1 へとアップデートすることになります。
また、原則として、その時点の最新版の rpm パッケージに対して、さらに修正を適用した新バージョンのパッケージが提供されますので、「現在使っている（不具合が発見された）パッケージに特定のパッチだけを適用した修正パッケージ」が提供されることはありません。例えば foo-1.0-1 を使用しているが、最新版が foo-1.2-1 である場合、 foo-1.0-2 あるいは foo-1.1-1 ではなく foo-1.2-2 あるいは foo-1.3-1 として提供されるため、不具合が修正されたバージョンを使用するためには foo-1.0-1 からfoo-1.2-2 あるいは foo-1.3-1 へとアップデートする必要があります。
RHEL のサポートポリシーより、 RHEL のメジャーバージョンが同じである間はアプリケーションの互換性が維持されています。例えば foo-1.0-1 を使用していて、当該 RHEL メジャーバージョン内での最新版が foo-1.3-1 であった場合、 foo-1.0-1から foo-1.3-1 へアップデートしてもアプリケーションの互換性は維持されます。従って、 RHEL に同梱されているパッケージを全て最新版にアップデートしても、設定ファイルの微修正やサービスの再起動などが必要になる場合があることと、想定外のリグレッションに遭遇する可能性があること以外には、問題が生じることは原則としてありません。
rpm パッケージには依存関係の情報が含まれていますので、依存関係を満たしている限りは、特定の rpm パッケージのみをアップデートすることも可能です。しかし、現在のシステムでは問題が発生していないとしても、潜在的な不具合やセキュリティ脆弱性が修正されていますので、 RHEL に含まれていないソフトウェアに起因した制約事項（例えばウイルス対策ソフトが最新のカーネルに対応していないなど）が無い限りは、アップデート可能なタイミングにおいて RHEL に含まれている全てのパッケージを最新版にアップデートしていただくことを推奨します。
RHEL の新しいマイナーバージョンが公開されると、古いマイナーバージョン向けのパッケージは原則として提供されなくなります。止むを得ない理由により最新のマイナーバージョンにアップデートできない場合には、 RHEL のサブスクリプション契約とは別に EUS 契約を結ぶことで、古いマイナーバージョン向けに提供される最新版のパッケージを入手できます。ただし、古いマイナーバージョン向けに提供されるパッケージは、原則として重大な問題のみを厳選して修正を行っているため、そもそも古いマイナーバージョン向けのパッケージが提供されない場合もあります。
RHEL のライフサイクルについては以下のページを参照ください。
rpm パッケージ管理の基礎知識
システムにインストールされている rpm パッケージの一覧は「 rpm -qa 」を実行することで確認できます。実行結果より、システムで使用しているアプリケーションの数としては少ないのにインストールされているパッケージの数としては多いこと、そして、各パッケージは階層構造ではなくフラットに扱われるため、当該パッケージが何をするためのものかを判断できないことに気づくでしょう。
パッケージのアップデートが公開されても原則としてインストールしないという運用をする場合、各パッケージに含まれるプログラムや設定ファイルなどが何をするためのものでどのように使われているかを理解しておくことは、システムへの影響範囲およびパッケージのアップデート要否を判断するために重要です。理解を手助けするための Linux カーネルの機能として TOMOYO というモジュールが存在していますが、 RHEL カーネルでは利用できないため、詳細については今回は触れません。
ソフトウェアのアップデートはパッケージ単位で行われます。必要に応じて調査対象のプログラムや設定ファイルなどがどのパッケージに含まれているのかを「 rpm -qf 調査対象のファイル」を実行することで確認します。パッケージ名を確認できたら、当該パッケージについての情報を「 rpm -qi パッケージ名」で、当該パッケージに含まれているファイルの一覧を「 rpm -ql パッケージ名」で確認します。そして、システムへの影響範囲を評価し、アップデート要否を判断します。
RHEL に同梱されている最新の rpm パッケージをインストールする場合、 rpm ファイルを入手して「 rpm --checksig インストール対象のファイル」で署名を確認後、 rpm コマンドを用いてインストールすることができます。しかし、 rpm ファイルの依存関係を扱う必要があるため、 rpm コマンドを直接実行するのではなく、 yum コマンドのように依存関係も処理してくれるツールを用いると便利です。 RHEL に同梱されているパッケージのインストール方法については以下のページを参照ください。
（半田哲夫）
コーヒーブレーク「Enterprise User's Meetingのパネルセッションに参加しました」
11 月 12 日、みなとみらいで開催された Linux Foundation のイベント、Enterprise User's Meeting 2014のパネルディスカッション「 OSS 導入最新動向 2014 」に参加してきました。モデレーターの小薗井さんの問いかけにしたがい、他のパネリストの方々と意見を交換する形で進行しましたが、本コラムにも関連する内容だったので、私が発言した内容について、思い出しながらご紹介したいと思います。
Linux Foundation 「 2013 年度オープンソースソフトウェア活用動向調査報告書」
について
- Q お勧め、あるいは注目しているOSSは？
-
- TOMOYO Linux および Hinemos
- プロジェクトマネージャとして関わった TOMOYO Linux については、開発者である半田のことをよく知っている。自分はカーネル開発者ではないが、プロジェクトの活動を通じて、彼のスキルを理解している。また、熱意、あるいは開発したものを活用して欲しいという強い思いをよく知っているので推薦したい。
- Hinemos については、出身である NTTデータの開発したオープンソースであり、それを開発しているメンバーと、技術と熱意、良いものを提供しようという姿勢を知っているので推薦できる。
- Q 活用動向調査結果の感想は？
-
- オープンソースに限らず、利用されなくなりつつあるソフトウェアや新たなソフトウェアは、ずっと入れ替わり続けている。その栄枯盛衰については特に感想はない。
- サポートに携わっている立場から気になったのは、「利用（使っている）」の内容。ここでは、主にインストールしているという意味だと思うが、トラブル対応等をどこまでプロジェクト（開発者あるいは運用者）でまかなえているかが気になる。
- ベンダー製品であればトラブルが発生したら、ベンダーに質問するしかない。しかし、オープンソースであれば、エラーメッセージを出力している箇所のソースコードを調べて（読んで）みることができるし、デバッグや場合によっては修正することもできる。
- そうしたことをしてこそオープンソースを活用していると言えるが、果たしてそうした使われ方をしているところはどのくらいあるか・・・。
OSSのセキュリティについて
- Struts1, bash, SSL など脆弱性について話題が続いたのが印象に残っている。
- サービスを提供していて脆弱性が発見されたら、ベンダー製品やオープンソースという分類がどうこうは関係ないし、「すみません。このソフトは EOL なので対応できません」とは言えないはず。
- 自分の所属に関わっているところで言うと、 Struts1については、 NTTデータでは独自にパッチを作成して、関連プロジェクトに展開、のちに公開している。また、 bash の脆弱性については影響範囲の確認方法について、 NTTデータ先端技術の ウェブページで「緊急コラム： bash 脆弱性（ CVE-2014-6271 ）の影響範囲の調査方法について」として、各利用者が調べるための方法を解説したところ、大変多く参照されている。
フリーディスカッション
- 新しいソフトウェアや技術が生まれ続けているが、最近そうした進化に疑問を持っている。。サポートに携わっていることもあり、安心、安定ということに関心がある。新たな機能を増やすことよりも、いかにトラブルの発生を避け、安定してサービスを提供するかを目標にすべきではないだろうか。
- サポートセンターは、聞かれたことに答えるところで、思ったことを言えないし、メッセージを伝えることができない。サポートセンターの「中の人」として、考えたことや感じたことを、「安らかな夜を迎えるために」と題して発信している。是非多くの人に読んで、参考にしてもらいたいと思っている。
（原田季栄）
Tweet