仕事中のソースマネージャーとパッケージマネージャー
アプリケーションをインストールする方法は2つあるので、少し混乱しています。 1つはソースから構成および作成することであり、もう1つはパッケージマネージャーから作成することです。 UNIX/Linux管理者の場合、パッケージマネージャーを使用することは公正であり、信頼できるでしょうか。私はいくつかの場所に出くわしましたが、今日の管理者は最初から物事を行うのではなく、パッケージ管理を好むため、実際に何をしているのかわからないと言っているようです。
ですから、意欲的なUNIX管理者として、私は両方の方法を知っている必要があることを知っていますが、どちらを先に選択する必要があります。例として、Apacheのセットアップを求められた場合の就職の面接で、ソースまたはパッケージマネージャーに連絡しますか？
私はいつも最初にパッケージマネージャーに行きます。ただし、ソースからコンパイルする場合：
- パッケージはひどく古くなっています。これは本来あるべきよりも一般的です。
- パッケージのデフォルトとは別の場所にインストールしたい。これはAmazon EC2インスタンスで頻繁に行うため、一時的なローカルストレージではなくEBSデバイスにインストールできます。
- アプリは、さまざまなオプションを使用するか、ソースパッチを使用してコンパイルする必要があります。 PHPは、ここで最も一般的な原因です。
- アプリはインストールしたいものの依存関係であり、パッケージマネージャーには一致するヘッダー/開発パッケージがありません。それほど一般的ではありませんが、時々発生します。
システム管理者として、ソースの処理方法を知っている必要があります...確かに。実稼働環境では、ソースからのパッケージを使用することをお勧めします。ディストリビューションのバージョンが要件をサポートしていない特定の状況でのみ言います。
ソースの問題は、アプリケーションのコードとそれが依存するライブラリにセキュリティパッチを適用する責任があることです。または、最新の安全なコードを維持するために継続的にバージョンバンプを行う必要がありますが、これはほとんどの場合、本番サーバーには適していません。ディストリビューションは、ポートセキュリティパッチを長年サポートしているバージョンに戻します。したがって、パッケージマネージャーにシステムを更新するように指示するだけで、セキュリティパッチを適用して最新の状態に保つことができます。これは、長期的にははるかに管理しやすくなります。
システム管理者として、あなたは誰があなたの後ろに来るかについても考える必要があります。ソースパッケージのミッシュマッシュを使用してシステムを継承することはそれほど楽しいことではなく、長期的には会社により多くの費用がかかります。
私はいくつかの場所に出くわしましたが、今日の管理者は最初から物事を行うのではなく、パッケージ管理を好むため、実際に何をしているのかわからないと言っているようです。
この声明は正確ではないと思います。確かに、システム管理者はソースからコンパイルする方法を知っている必要があり、少なくとも一度もコンパイルしていないことは非常にまれです。
しかし、人生のすべてが、どの方法を使用すべきかを決定することは、自分の要件に基づいています。
1）公式ディストリビューションのパッケージバージョンが機能のニーズをカバーしている場合、答えは明らかです。パッケージシステムを使用してください。パッケージシステムが提供する容易さには言い訳はありません。すべての依存関係が自動的にインストールされ、作業は構成ファイルで制限されます。最も有名なディストリビューション（Redhat、Centos、debian）は、すべてのセキュリティパッチをバックポートするため、公式パッケージを常に更新します。また、セキュリティ更新は自動的に更新されるため、心配する必要はありません。これは、パッケージに新しい更新があるかどうかを常にチェックするのではなく、システム管理や監査などに時間を費やすため、運用サーバーで非常に役立ちます。
2）プロジェクトに、必要なアプリケーションの最新バージョンのみが提供する最新の機能が必要な場合は、すべてをソースからコンパイルする必要があります。これには時間がかかり、新しいバージョンにセキュリティバグが発生するかどうかを常に監視する必要があります。次に、すべてを再コンパイルする必要があります。欠点は明らかです。ただし、複数のサーバーを管理する必要がある場合は、問題はさらに大きくなります。この場合、最も簡単な方法は、独自のリポジトリを構築し、最新バージョンのソースコードに基づいて独自のパッケージを構築してから、各サーバーのパッケージマネージャーを再度使用して、リポジトリを使用してパッケージを更新することです。
puppet、chef、cfadminなど、あらゆる種類の自動構成管理を使用する場合は、*の方法に慣れている必要があります。 nixのパッケージは機能します。 EnterpriseまたはLTSディストリビューションを使用している場合は、通常、更新されたパッケージが含まれているため、優れたサードパーティリポジトリがどこにあるかも知ってください。
ソースから何かをコンパイルする必要がある場合は、一貫したレイアウトと命名スキームを使用することをお勧めします。 autoconfがどのように機能するかを読み、--prefixディレクティブを利用します。
個人的には、カスタムコンパイルされたものを/optにインストールするのが好きです。
/opt/nginx/nginx-0.6.44
次に、currentシンボリックリンクを作成します
/opt/nginx/current
次に、パッケージのすべてのバイナリを次のような既知の場所にシンボリックリンクします。
/opt/bin
例えば
cd /opt/bin && find /opt/nginx/current/bin -type f -exec ln {} \;
/opt/binを$PATHに追加できるようになり、nginxのバージョンを切り替えるのは、新しいバージョンを/opt/nginx/nginx-$VERSIONにインストールしてシンボリックリンクを更新するのと同じくらい簡単です。
今日の管理者は、ゼロから物事を行うのではなく、パッケージ管理を好むため、実際に何をしているのかわかりません。
管理者は彼らが何をしているのかわからない彼らはパッケージ管理を使用することを選択しないので、私は思いません。パッケージマネージャーを使用する理由はたくさんあります。私は彼らが彼らが何をしているのかわからない彼らが理解するのに時間がかからないときだと思います。パッケージ管理システムがどのように機能するか、独自のパッケージを構築する方法、または独自のパッケージをいつ構築する必要があるか。
通常、RedhatやUbuntuなどのディストリビューションから商用サポートを受けることができます。自分で作成したものではなく、公式にサポートされているパッケージを使用している場合は、サポートを受けるのがはるかに簡単になります。
製品を実際に機能させるために、公式にサポートされているパッケージを使用する必要がある商用アプリケーションもいくつかあります。
UNIX/Linux管理者の場合、パッケージマネージャーを使用するのは公平であり、信頼できるのでしょうか。
Redhat、Ubuntu、Debianなどの公式の主要なディストリビューションからのパッケージの利点は、多くの人々がそれらを使用していることであり、数に強みがあります。すべての主要なディストリビューターは、パッケージを自分で再構築するために必要なソースを提供しています。しかし、ディストリビューターがパッケージを作成することを信頼していない場合、ダウンロードしたソースに何も問題がないことをどのように信頼できますか？ソースコードのコード監査を実行するスキルはありますか？ソースのバックドアや悪用可能なバグを検出できますか？オペレーティングシステムに入るコードのすべての行を確認する時間がおそらくないため、ある時点で誰かを信頼する必要があります。
就職の面接で、Apacheのセットアップを求められた場合、ソースまたはパッケージマネージャーに連絡しますか？
質問に答えるには、要件を調べるために少し時間がかかる必要があります。就職の面接で適切な種類の質問を頻繁に行うことは、単純な回答よりも印象的です。また、1つの方法を選択して、その方法が優れている理由と、その方法が悪い理由をいくつか説明することもできます。
- 安定した商用サポートが必要ですか
- 有効になっていない異常な機能が必要ですか？
- 将来的には複数のサーバーをサポートする予定ですか
- ネットワーク上でApacheを実行しているホストが十分にあり、アップストリームのセキュリティフィードとセキュリティリストを独自に監視できますか。
アプリケーションをインストールする方法は2つあるので、少し混乱しています。 1つはソースから構成および作成することであり、もう1つはパッケージマネージャーから作成することです。
3番目のオプションをスキップしました。独自のパッケージを構築し、パッケージマネージャーによって参照されるローカルリポジトリを維持します。独自のパッケージを構築することをお勧めします。構築したものが標準システムの一部になるためです。パッケージマネージャーに精通している人は、それをアンインストールする方法を知っているでしょう。彼らはそれについての情報を得ることができるでしょう。
評判の良い場所からパッケージを入手している場合は、おそらく大丈夫です。 apt-getを使用してApacheをインストールすることについて特に不満はありませんが、重要ではない機能には主にLinuxを使用していることに注意してください。