いくつかの質問が混ざっているので、それぞれ答えていきます。
###パッケージ版とOSS版の一番の違いはサポートの有無
一番の違いはサポートの有無です。
パッケージ版はRed Hat社がその動作を商用サポートしており、問題があったときはRed Hat社へ問い合わせをする事ができます。Red Hat社は最後まで責任を持って、問題の解決に向けてサポートしてくれます。RHELのサブスクリプション費用が高いのも、このサポートがあるからです。
OSS版はそのような責任があるサポートはしてくれません。メーリングリスト等でApacheのコミュニティーに質問することはできますが、答えてくれるとは限りませんし、その答えに責任を持ってくれることもありません。うまくいかないときに、開発元のApache財団へ文句を言うのは筋違いです。Apacheのライセンスに「私達は一切の責任を持ちません」とはっきり明記してあり、それに同意しなければ、そもそも使用してはいけません。
このサポートの違いは小さくありません。そもそもサポートが不要であれば、RHELではなくCentOSで十分だったはずです。
###パッケージ版とOSS版を入れ替えるときの注意事項
現実的に入れ変える必要がでてきたとして、その違いや注意事項を述べていきます。
- OSS版ではコンパイル環境を整える必要があります。GCC等のコンパイラはもちろんですが、openssl-develと言ったヘッダ等が含まれる開発パッケージもいくつか入れておく必要があります。(必要になる開発パッケージは、コンパイルするモジュールによって異なります。)
- パッケージ版はモジュールを個別にインストールすることができますが、OSS版はコンパイル時にモジュールを選んでおく必要があります。(OSS版でも後からモジュールを追加することはできますが、いささか面倒です。)
- Apache HTTP Serverに含まれないモジュールもパッケージとして提供されている場合があります。それらのモジュールは、Apache HTTP Serverとは別に、同じくコンパイルして入れる必要があります。例えば、PHPのmod_php等がそうであり、phpパッケージのmod_phpを使用せずに、PHPのコンパイルから始める必要があります。(もしかしたら動く可能性はありますが、推奨はしません)
- OSS版ではsystemd関係の設定ファイルは一切用意しません。パッケージに含まれるhttpd.serviceを参考にしながら、自分で用意する必要があります。パッケージ版のファイルを上書きした場合、アップデート等でさらに上書きされて予期せぬ動作になりますので、絶対にやめて下さい。サービス自体を別にして、パッケージ版のサービスを落とし、OSS版のサービスを起動するようにしてください。
- OSS版ではSELinux関係の設定は一切行いません。パッケージのSELinux設定を参考にしながら、自分で設定する必要があります。
- パッケージ版とOSS版ではコンフィグファイルの構成が異なります。モジュールファイルへのパスなども異なるため、そのまま使用することはできません。よく理解した上で、設定の書き換えや設定ファイル、モジュールファイルの配置を手動で行う必要があります。
- OSS版をパッケージ版があった場所にバイナリを上書きするようなことはやめてください。パッケージは単なるバイナリファイルの集合ではありません。多くの設定からの集合体であり、パッケージで入れたバイナリであることを前提にしています。上書きしただけで動くこともありますが、それは偶然に過ぎません。
- OSS版で入れた場合、パッケージの管理外になります。パッケージのバージョン等を一元管理している場合は、その対象から外れます。脆弱性情報などは自分で集め、自分で対象バージョンか確認する必要があります。
- OSS版では最新版が使用できるため、新機能が使えます。OSS版で新機能を使った場合、パッケージ版へ戻すことはできません。(ディストリビューションのメジャーバージョンが変わらない限り、パッケージ版に新機能が追加されることは原則ありません。)
- OSS版はコンパイル時に柔軟な選択が可能です。不要な設定を初めからオフにしたり、モジュールを組み込みにしたりできます。ただし、よく理解した上で選択しないと、パッケージ版と同じにはなりません。
なお、新バージョン用のSRPM(ソースから入れるRPM)を作ると言う方法もあります。ただ、httpdパッケージ以外の多くのパッケージも用意する必要があるため、それなりの知識がないと難しいです。
大昔に、どうしてもApache HTTP Serverの新機能が使いたくて、最新のOSS版に入れ替えと言うことをした事がありますが、新規でOSS版のApache HTTP Serverを入れることとほぼ同じぐらいの工数になりました。つまり、さくっと入れ替えると言うことはできません。新たにサーバーを一つ作って(ただし、OSの初期設定だけ済んでいる)、そこにコンテンツを移行するぐらいのとおなじぐらいの物だと思ってください。
なお、いざOSS版で運用するとなった場合、OSS版のアップデートはコンパイルから始まりますので、それなりの工数がかかります。夜間にアップデートを走らせておくなんて事も(スクリプトなどを組めばできないことはありませんが)基本的にはできないと思ってください。
###RHELはなぜFixしないのか?
最後に、なぜRHELはこれらをすぐにFixしないのかです。と言っても、私はRed Hat社の社員では無いので、以下は推測になることを予めご了承ください。
別にReh Hat社がサボっているわけではありません。緊急度が高い脆弱性が出た場合は、1~2日後には大抵パッチを出すようにしています。しかし、今回は緊急度が低い脆弱性であったと言うことです。
一言で脆弱性と言っても緊急度の高さが異なります。CEV 2017-7679の情報について見てみましょう。
CVE-2017-7679 - Red Hat Customer Portal
CVSS v3 metricsが緊急度の高さの目安であり、深刻度という評価では3.7です。このCVSS v3の見方はIPAが資料を出してくれているので、下記を参考にしてください。
共通脆弱性評価システムCVSS v3概説:IPA 独立行政法人 情報処理推進機構
ぶっちゃけていうと、放置してもそれほど問題が出ない脆弱性と言うことです。Reh Hat社の方針としては、多くの顧客で安定して稼働することを第一としています。深刻度が非常に高い、例えばCVE-2014-6271(ShellShockの一つ、深刻度は9.8)のような脆弱性は、なりふり構っていられませんので、すぐに対応します。しかし、
- デフォルトでは無効のマイナーな設定を有効にしないと攻撃を受けない。
- 攻撃の成功には運の要素が絡み、確率が非常に少ない。
- 攻撃が成功しても、DOSや一部の情報漏洩(絶対に機密にしなければならない部分では無い)のみで、深刻な影響を受けない。
と言った場合、パッチを当てることによって不安定になるリスクを背負うことよりも、安定して稼働し続ける方を選択します。そのため、すぐにパッチを用意しない、または、全く用意しない場合もあります。また、会社としてのリソースも無限ではありませんので、緊急性が低い物は後回しにするというのもあります。
脆弱性は何でもかんでも単に対応すれば良いという物ではありません。脆弱性の対応というのは、パッチを作る側にもそれなりの工数が必要であり、また、そのパッチによって不安定になったり別の脆弱性が産まれるリスクが常につきまとう物です。それらを考慮して、バランス良く対応する必要があると言うことです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/23 06:53