私は、サーバーをホストするために Fedora を何度も使用してきました。これまで、問題に遭遇したことは一度もありません。それでも、新しいユーザーは皆、Fedora は安全ではないと言います。Ubuntu / CentOS または他のディストリビューションを使用するべきであり、Fedora は使用すべきではありません。Fedora の何が問題なのか、私には理解できません。他のディストリビューションの何がより安全なのか。
いくつかのポイント: 1. Fedora には、SSH のみを許可するように構成された iptables が付属しています。さらに、必要に応じて、いつでも iptables を構成して SSH をブロックすることもできます。したがって、ファイアウォールに不足はありません。
Fedora は定期的にアップデート (セキュリティ パッチと一般パッチの両方) をリリースします。
ディストリビューション X は 5 年に 1 回、Fedora は 6 か月に 1 回新バージョンをリリースすると言われています。5 年に 1 回のリリースで安全になるのはなぜでしょうか。5 年前のものが安全だと感じる場合は、5 年前の OS をインストールするか、新しいバージョンがリリースされても 5 年間はアップグレードしないでください。個人的には、5 年間新しいバージョンを提供しないことでセキュリティが向上するとは思いません。バグが検出されるたびに 5 年間パッチをリリースする必要があります。つまり、非常に古い OS を使用するということは、パッチが増えることを意味します。最近リリースされたバージョンを使用する場合は、適用する更新/パッチが少なくて済みます。5 年に 1 回のリリースで安全になる理由が理解できません。
すべての OS は、Gnome、Open-Office、KDE、Open-SSH、Apache などの同様のパッケージを使用しています。他のディストリビューションの開発者は、これらのパッケージのソース コードを読んで、セキュリティ エラーがあれば修正するのに時間を費やしているでしょうか。たとえそうしなかったとしても、彼らはそれらの欠陥を公開し、Fedora を含む他のすべてのディストリビューションがパッチをリリースするでしょう。または、彼らは独自のディストリビューションをセキュリティ保護し、他のディストリビューションに通知する手間を省くでしょうか。これはすべて、apache、gcc、Open-Office のような大規模なパッケージの何百万行ものコードをすべて読んでいることを前提としています。これがすべてのディストリビューションで同じである場合、Fedora の脆弱性を高めるものは何でしょうか。
Fedora には seLinux がプリインストールされ、適切に設定されています。
Fedora では、Bind はデフォルトで chroot で実行されます。Fedora 11 では、DNSSEC サポートもデフォルトで提供されます。質問を参照してください。Fedora 11 上の DNS サーバー誰かが Fedora は DNS のホスティングには適していないと指摘しました。理由はわかりません。
実際、新しい管理者の 1 人がテスト マシンの 1 つに Cent-OS 5.3 をインストールしました。私はそれを使用して、存在しない 1 つの IP に ping を実行しました。ping 応答が返ってきました。それが不可能だったので驚きました。応答がどこから来ているのかを見つけようとしましたが、失敗しました。1 時間以上試した後、最終的に CentOS マシンからネットワーク ケーブルを取り外しました。IP にはまだ ping できました。次に、マシンの IP アドレスに ping を実行してみました。それにも ping できました。つまり、マシンが 1 つの IP で構成され、エイリアス (eth0:1 など) が存在しない場合、2 つの IP (他の IP ではありません。それらも試しました) に ping を実行できました。ifconfig の出力も確認しました。私はいわゆるサーバー ディストリビューションへの完全な信頼を失い、すべてのテスト マシンに Fedora 11 をインストールしました。今では、ping のような基本的なことでこのような奇妙な問題に直面することはありません。
Fedora が安全でないことを示す実例を教えていただけると大変ありがたいです。その場合、他のディストリビューションであれば問題なかったでしょう。管理者がミスをした例は挙げないでください。ディストリビューションを責めることはできません。また、非常に古い Fedora 1、2、または Fedora 3 の例も挙げないでください。Fedora プロジェクトは、特に最近の 2 つのバージョン 10、11 では非常に成熟しています。これらのバージョンに特有のセキュリティ問題に直面したことがある場合は、ぜひ経験を共有してください。
答え1
Fedoraがサーバーでの使用に適していないということはありませんし、「サーバーディストリビューション」がサーバーに唯一の選択肢であるということも何もありません。あなたの特別なニーズ。
「サーバー ディストリビューション」を使用することで得られるメリットは次のとおりです。
- 長期サポート
- 安定した API (ライブラリやアプリケーションのバージョンアップグレードはほとんどまたはまったくありません)
- バックポートされたセキュリティ修正とバグ修正
- 有料サポート
サーバー ディストリビューションに対する私の主な「不満」は、ソフトウェア/ライブラリがやや古い傾向があり、サポートされるパッケージの範囲がコミュニティ主導の取り組みよりもはるかに狭いことです。
つまり、長期サポートと変更されない API は、商用ソフトウェア ベンダーが好むものであり、API が突然変更されたために最新のライブラリ用にアプリケーションを再構築する必要がありません。ベンダー Y リリース X 向けに開発でき、このプラットフォームが今後数年間は存続することがわかります。
答え2
これについては何も付け加えることはないと思っていましたが、非常に重要な Zabbix 監視システムのために、ほぼ 2 年間 Fedora を本番環境で実行した後、いくつか言いたいことがあるようです。
まず、これは私の第一候補ではありませんでした。通常、少しでも重要なことであれば、これらのディストリビューションが提供する長期的な安定性の利点のために、CentOS/RHELを選択します。しかし、この特定の展開では、Zabbix 2.0の機能が絶対に必要でしたが、エペルリポジトリは 1.8 のみを提供しました。(EPEL には現在、1.8 に加えて Zabbix 2.0 および 2.2 パッケージがありますが、当時はありませんでした。もしあったら、私はこれを試すことはなかったでしょう。)
ここでのトレードオフは、Fedora には最新のソフトウェアが搭載されていますが、リリースのライフサイクルが非常に短い 13 か月で、新しいリリースは約 6 か月ごとに行われるということです。つまり、通常の定期的なアップデートのインストールに加えて、年に 2 回 Fedora をアップグレードするためのメンテナンス ウィンドウを計画する必要がありました。
監視システムは、ほかのすべて、このようなメンテナンス期間はできるだけ少なく、短くすることが重要です。頻繁にアップグレードする必要があるため、通常はこのようなディストリビューションは除外されますが、私にはもっと差し迫った懸念があったことを思い出してください。必要な機能がなければ役に立たないからです。したがって、これは、結果を（ほぼ）十分に理解した上で行ったトレードオフです。
少し前に、Fedora の新しい fedup アップグレード ツールを使用して、このサーバーで Fedora 18-19 へのアップグレードを実行しました。2 時間の停止を計画し、さらに 2 時間かけて、Zabbix がダウンしたために監視対象サービスが停止し、その事実が見逃された可能性がある場合に対処する予定でした。
の実際のサービスのダウンタイムは 11 分でした。これは、再起動前に Zabbix が停止した時間から、アップグレード完了後に Zabbix が復旧してサービスを監視するまでの時間です。ダウンタイムがこんなに短いとは思いませんでした。もっと大変なことになると思っていた経験上、Fedoraでは重大なアップグレードの問題はまれだとわかっていますが、それでもです。（そしてさらに改善されました。Fedora 19-20にアップグレードしたとき、完全なダウンタイムは驚くべきものでした。6分20-21も同じ時間です。
このサービスは、RHEL 7 が利用可能になったときに、ほぼ確実に移行されます。この経験から、私はサーバーとしての Fedora にさらに自信を持つようになり、6 か月ごとにメジャー アップグレードが行われても、Fedora を維持するつもりです。RHEL への移行は、次の理由により、はるかに混乱を招き、将来的に制限される可能性があります。
Red Hat のメジャー リリースの間隔が長いのは残念です。EL5 と EL6 の間にも同様の遅延があったため、Ubuntu インストールを実際に運用することになったのですが、今でもそのことを後悔しています。(そのシステムでは Fedora を検討しましたが、奇妙なことに、古いバージョンが EPEL にあったにもかかわらず、当時は必要なソフトウェアがまったくパッケージ化されていませんでした。)
Fedora を実行する際に誰も言及しなかった「問題」の 1 つは、大規模なソフトウェア プロジェクトと小さな機能強化の両方を含む多くの新機能が、RHEL に組み込まれるよりかなり前に登場することです。そのため、RHEL/CentOS システムを管理するときに、それらの新機能を見逃すことになります。たとえば、Fedora には、RHEL にまだデフォルトで含まれていない bash 補完が多数あります。注目すべきものの 1 つは、yumコマンド ラインでのパッケージ名のタブ補完です。
したがって、トレードオフを受け入れられる限り、Fedora を本番環境で使用することは確かに可能です。
- サポート契約はありません。サーバーとそのサービスを管理し、発生する可能性のある問題に対処するのに十分な社内専門知識が必要です。利用できるのはコミュニティ サポートのみで、保証はありません。RHEL と RHEL は非常に似ているため、RHEL の経験が役立ちます。
- メンテナンス期間を設ける必要があります少なくとも年に1回はアップグレードするただし、6 か月ごとのほうが望ましいです。毎年アップグレードすると、一度に 2 つのリリースをアップグレードする必要があり、午前 3 時に対処しなければならない潜在的な問題の数が 2 倍になります。
- アップデートによりソフトウェアの新しいバージョンが提供される場合があり、それに対処する必要がありますが、これらはポイントリリースであり、メジャーバージョンではありません。まれに、重要な新機能が追加される場合があります（例：BZ#319901ただし、通常、ソフトウェアはリリースの有効期間中は同じバージョン番号のままで、修正がバックポートされます。一部のパッケージ (PHP など) のみがアップストリーム ポイント リリースを追跡します。
- セキュリティ アップデートのペースに大きな違いはありませんが、バグ修正アップデート (PHP など) から必ずしも分離されているとは限りません。これが問題になるかどうかは、実行を計画しているサービスによって異なります。
すべてを考慮すると、Fedoraは依然としてサーバプラットフォームとして私の第一の選択肢ではないし、おそらく今後もそうはならないだろう。（私はこれまでFedoraに満足していたが、デスクトップ(存在全体を通じてユーザーです。) より「エンタープライズ」なディストリビューションでは利用できない最新バージョンのソフトウェアが絶対に必要であり、トレードオフを受け入れることができる場合は、Fedora を使用しても問題はありません。
最後に、セキュリティについて具体的に質問されたので、それについて少しお話しします。
前述のように、Fedoraと他のディストリビューションのセキュリティアップデートのペースに実質的な違いはありません。Fedoraのパッケージ作成者は、上流に近づくそして、こうした種類のアップデートをできるだけ早く、場合によっては上流のプロジェクトよりも先にリリースします。
エンタープライズ向けの兄貴分であるFedoraも、セキュリティ設定がかなり厳重にロックされています。サービス（SSHを除く）はデフォルトでオフになっています。デフォルトで拒否されるファイアウォールはIPv4とIPv6の両方で有効になっています。SELinuxはデフォルトで強制されています。さらに、Fedoraは他の多くの方法で強化されています。
一方、新しいセキュリティ技術を非常に早い段階で目にすることができます。一例として、最近導入されたファイアウォールD、まだゴールデンタイムには間に合わないが以前のファイアウォールに戻すのは簡単です。
答え3
本質的には、セキュリティよりも安定性と変更率を重視します。Fedora は、Red Hat が新しい機能やアプリケーションを展開してその関連性を検証し、実験用のプラットフォームを提供し、統合の問題を解決するためのプラットフォームです。
通常、これはサーバーに期待する動作ではありません。一般的に、サーバーには可能な限り安定した方法で機能を実行することが求められます。
何をしているかにもよりますが、Fedora で十分でしょう。Linux デスクトップ アプリを開発している場合は、最先端の技術で作業することが望ましいかもしれません。同様に、学期にわたる学校のプロジェクトや、変更のテンポが速くても問題にならないその他の期間限定のプロジェクトに取り組んでいる場合も、Fedora で十分です。
答え4
サポートなし。
Fedora には、Red Hat Enterprise のような技術サポート契約がありません。致命的な問題が発生した場合に電話できる相手がいません。