目的
私たちの目標は、RPMベースのシステムでのパッケージの依存関係に関する情報を見つけるために利用できるツールに慣れることです。
オペレーティングシステムとソフトウェアのバージョン
- オペレーティングシステム： Red Hat Enterprise Linux 7.5
- ソフトウェア： rpm 4.11、yum 3.4.3
要件
システムへの特権アクセス。
難易度
簡単
規約
- ＃ –指定されたLinuxコマンドは、rootユーザーとして直接、または
sudoを使用して、root権限で実行する必要があります。 コマンド - $ –通常の非特権ユーザーとして実行されるLinuxコマンドを指定
はじめに
RPMはRedHatPackage Managerの略で、SuSEだけでなく、すべてのRedHatフレーバーディストリビューションで使用されている有名で成熟したパッケージマネージャーです。 RPMを使用すると、パッケージャーはパッケージ間の関係を定義できます。たとえば、Apache Tomcatサーバーを実行するには、適切なJava環境が存在する必要があります。
一方、Java環境をインストールするには、Tomcatサーバーは必要ありません。別のJavaベースのアプリケーションを実行することもできます。たとえば、必要に応じて自分で作成したアプリケーションを実行することもできます。つまり、Tomcatサーバーは依存します。 Javaで。
RPMは、これらの依存関係と、rpmなどのRPMに依存するツールを提示することで、システム管理者の作業を大幅に楽にすることができます。 ユーティリティ、またはyum これらの依存関係を自動的に解決し、新しいコンポーネントを正しく実行するために必要なすべての追加パッケージをインストールできます。
情報の収集
foo.barパッケージが依存しているパッケージのリストを見つけるには、次のコマンドを実行するだけです。
# yum deplist foo.bar
そして、パッケージfoo.barを必要とする（依存する）パッケージのリストを見つけるには：
rpm -q --whatrequires foo.bar
一般的なパッケージを使用した実際の例：bash 。 bashパッケージに必要なパッケージを見てみましょう：
# yum deplist bash
package: bash.x86_64 4.2.46-30.el7
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.11)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.14)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.15)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.8)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libtinfo.so.5()(64bit)
provider: ncurses-libs.x86_64 5.9-14.20130511.el7_4
dependency: rtld(GNU_HASH)
provider: glibc.x86_64 2.17-222.el7
provider: glibc.i686 2.17-222.el7
パッケージの観点から、bash は非常に一般的なものであり、上記のように、いくつかのコアパッケージに依存します。ただし、もっと依存度の高いものをインストールしたい場合は、たとえばkonzole Gnomeデスクトップマネージャーを搭載したRedHatLinux上のKDEターミナルエミュレーターでは、複数ページの依存関係リストを取得する場合があります。そしてkonzole 、ケースはQTおよびKDEパッケージに依存しているため、さらに複雑です。したがって、インストールするには、Gnomeの横にKDE環境全体をインストールして（確実に実行できること）、すべてを提供する必要がありますkonzole ニーズ。
インストールされるパッケージの詳細については、インストールを開始する前に、yumが提供するリストを確認してください。
# yum install konsole
Resolving Dependencies
--> Running transaction check
---> Package konsole.x86_64 0:4.10.5-4.el7 will be installed
--> Processing Dependency: konsole-part = [...]
Gnomeを使用するRedHatシステムの場合、KDEアプリケーションの依存関係を初めて解決するのにかなりの時間がかかる場合があります。それが完了すると、yumは私たちが要求した唯一のパッケージを小さなサイズで提示します。 。依存関係のためにインストールされた100以上のパッケージが続きます：
[...]
--> Running transaction check
---> Package boost-system.x86_64 0:1.53.0-27.el7 will be installed
---> Package boost-thread.x86_64 0:1.53.0-27.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================
Installing:
konsole x86_64 4.10.5-4.el7 rhel-7-server-rpms 78 k
Installing for dependencies:
OpenEXR-libs
[...]
要約すると、インストールでは最終的にディスク上でより多くのスペースが使用され、次に必要なパッケージのサイズが使用されることがわかります。
[...]
Transaction Summary
==============================================================================================================================
Install 1 Package (+120 Dependent packages)
Total download size: 108 M
Installed size: 307 M
これはたくさんありますが、どのくらいのスペースが使用されるかについての有用な情報を入手しました。これは、1つのトランザクションで多数のパッケージをインストールする場合に特に便利です。
この場合、トランザクションは無駄になりますが、依存関係の目標は最終的にリソースを節約することです。誰かが自分のコードに何らかの機能を実装し、それをシステムで呼び出すことができる場合、次の開発者は同じ機能を実装する必要がない場合があります。繰り返しますが、既存の実装を使用してください。 konzoleの場合 たとえば、akregatorをインストールする場合 次回は、kdepimのように、システムですでに多くの依存関係が解決されています。 akregatorを含むパッケージ qtにも依存しています 、kdelibs 、など。
rpmを使用できます ユーティリティは、逆に情報を取得します。bashを必要とするインストール済みパッケージを一覧表示しましょう。 パッケージ：
# rpm -q --whatrequires bash
dracut-033-535.el7.x86_64
initscripts-9.49.41-1.el7.x86_64
autofs-5.0.7-83.el7.x86_64
lvm2-2.02.177-4.el7.x86_64
rsyslog-8.24.0-16.el7.x86_64
不要なパッケージのクリーニング
システムを最新の状態に保ち、その役割を変更または拡張すると、必然的に「ジャンク」パッケージが表示されます。パッケージの意味では、ジャンクとは、不要になったパッケージや非推奨のパッケージを意味します。上記の例に従うために、akregatorはもう必要ありません 、RSS処理の「サービス」をシステム内の架空の中央RSSコンセントレーターに移動したため、フィードを中央の場所に移行した後、ローカルRSS処理アプリケーションをアンインストールします。他の多くのパッケージがそれらに依存している可能性があるため、すべてのKDEパッケージが削除されるわけではありません。ただし、そうでない場合、これらのパッケージはジャンクであり、yumのように、更新時間が長くなるなどのリソースを消費します。 デフォルトでは、すべてを盲目的に更新し、新しいパッケージ/エラッタを検出します。
ブロードバンド接続とSSDを備えたラップトップでいくつかの不要なパッケージをアップグレードするためにリソースを費やすことは問題ではないように思われるかもしれませんが、数百または数千台のコンピューターを備えたデータセンターを想像してみてください。一般に、すべてのシステムをシンプルに保つことをお勧めします。リソース管理は1つのポイントにすぎません。システムが複雑になるほど、エラーが発生しやすくなります。コンポーネントが多いほど、バグの可能性が高くなります。
システムにインストールされている不要なパッケージの概要を把握するには、CentOSと同じ方法でyumとpackage-cleanupを使用するか、yumの別の機能であるautoremoveを使用します。 ：
yum autoremove
これらのツールが不要としてマークするパッケージは同一ではありません。
これらのツールのいずれかを使用する場合は、yumを再確認することをお勧めします。 実稼働システムをクリーンアップする前に、削除し、場合によっては、同じパッケージコンテンツのテストマシンでクリーニングの結果をテストします。
これらのツールは確かに賢いですが、すべてを知っているわけではありません。たとえば、cupsを呼び出すWebサーバー上で実行されているカスタムPHPアプリケーションに関するエントリはrpmデータベースにありません。 サーバーに接続されたプリンターで受注を印刷します。つまり、できる アプリケーションが適切な依存関係を含むようにパッケージ化されており、rpmで適切にインストールされている場合は、エントリになります。 またはyum –ただし、これには手間がかかります。yumベースの自動クリーンアップで安全を確保したい場合は、すべてのサービスを同じ方法でパッケージ化する必要があります。
依存関係の問題の解決
特に大規模な環境では、システムのインストールまたはアップグレード中に依存関係の問題が発生する可能性があります。
以下のスクリーンショットは簡単な問題を示しています：
rpmで依存関係を解決する
上記のターミナル画面で、nrpeをインストールしようとしています パッケージでは、クライアントはNagiosを使用してシステムの多くの側面を監視する必要がありました。配布用にクライアントをダウンロードしましたが、両方ともrpm およびyum 同じエラーで失敗します：nrpe パッケージにはnagios-commonが必要です（依存します） パッケージ。この例では、同じソースから必要なパッケージを取得でき、両方をインストールするときにrpm ユーティリティは、以前に失敗した依存関係がトランザクションの終了までに満たされることを確認し、両方のパッケージをインストールして、成功してサイレントに終了します。
結論
Yumとrpmは、RPMパッケージマネージャーを使用してディストリビューションを操作する場合に不可欠なツールです。ツールセットを知っていると、特定のシステムのソフトウェア環境でのインストール、アップグレード、および変更タスクを解決するのがはるかに簡単になり、通常はより安全になります。