
弊社のビジネス サーバーでは、さまざまな理由から rpm パッケージを使用したいのですが、rpm パッケージをシステム データベースにインストールできません (権限、複数のインスタンスなど)。そのため、独自のローカル rpmdb を作成し、非ルートとして --dbpath 引数を使用してパッケージをインストールしています。そのため、現在、ローカル db には 10 個のパッケージしか含まれていない可能性があります。これはうまく機能し、非ルート インストールが可能で、複数の rpmdb が使用されているため、同じパッケージの複数のインスタンスが可能になります。欠点は、ローカル データベースはシステム レベルでインストールされたパッケージを認識しないため、すべてを --nodeps でインストールする必要があることです。
--nodeps 問題を解決するために、現在のシステム db を使用してローカル データベースを初期化する方法がいくつかあります (たとえば、/var/lib/rpm/Packages をコピーして再構築するだけです)。次に、アプリケーション パッケージをその上にインストールすると、依存関係を完全に使用できるようになります。ただし、最初のコピー後にシステム パッケージを同期させる方法が問題です。管理者がシステム パッチをインストールすると、システム rpmdb のみが更新されます。更新を比較し、データベースのみの更新をローカル コピーに適用する夜間バッチ ジョブを作成する方法を探しています。
これを実現するためにどのようなコマンドが使用できるかお考えはありますか?
ご協力ありがとうございます。ブライアン
答え1
--nodeps
、再配置可能なパッケージ、および Berkeley DB の手動管理は、それぞれ面倒です。3 つすべてを実行したいですか? これはお勧めしません。パッケージ管理において 20 年後退することになります。FedoraやELのパッケージで再配置可能なものはほとんどありませんなぜなら、yum では管理できないからです。さらに、nodeps は、yum では簡単に修正できない依存関係に陥る可能性があることを意味します。
必要なインスタンスごとにユーザーに「ホスト」を提供します。VM、コンテナ、chroot ( yum --installroot
) など、これらのいずれも RPM と格闘する時間よりも安価になる可能性があります。
プロビジョニングを自動化します。ユーザーがパッケージ セットの変更を提案し、タイムリーにレビューされるような手順を用意します。一部のユーザーにインスタンスをテストする権限を与えて、重要なものを壊すことなく試せるようにします。
再配置や代替 rpmdb を必要としないようにすべてを再パッケージ化します。競合しないパスに移動し、名前にバージョン番号を含む個別のパッケージを作成します。一般的には、Fedora RPM パッケージ化ガイドラインに従います。その後、パッケージは yum で管理できます。