web-dev-qa-db-ja.com

LinuxまたはSolarisのデフォルト以外のパスにパッケージをインストールする方法は?

「デフォルトパス」とは、「/usr/local」、またはルートによって管理されるその他のパス(「システムパス」)を意味します。

多くのアプリケーションパッケージをインストールする必要があります(つまり、svnhttpdgitPerlpython、。 ..)いくつかのLinux(RedHat)またはSolaris(10、 ローカルゾーン )サーバー。

だが:

  • それらのサーバーは多くの異なるアプリケーションを管理します(svnまたはPerlの異なるバージョンを使用することもあります...)
  • 私はそれらのサーバーの管理者ではありません(私にはSudo rootはありません)

たとえばSolarisで、pkgadd -Rを使用して、プリコンパイル済みパッケージをカスタムパス(つまり、通常のデフォルトパスである/usr/local/...ではなく、特定のユーザーのhomedir内)にインストールしてみました。 、しかし、プリコンパイルされたパッケージはすべて/usr/...の他のリソースへの参照が付属していると述べました。

ldd /path/to/local/installed/packagesは、システムパスへの多くの依存関係を示します。

ldd /home/myuser/usr/local/git
  libz.so => /usr/local/lib/libz.so
  libiconv.so.2 => /usr/local/lib/libiconv.so.2
  libsocket.so.1 => /usr/local/libsocket.so.1
  ...

それはしません、なぜなら:

  • Solarisでは、ローカルゾーンからではなく、グローバルゾーンからのみ書き込み可能な/usrに何かを書き込む方法がありません。
  • SolarisまたはLinuxでは、とにかくrootではないため、システムパスに何も書き込むことができません。
  • 私はこれらのサーバーのアップグレードを管理していないため、ライブラリが変更されると、インストールされているサービスの多くが破損する可能性があります。

同じ(LinuxまたはSolaris)サーバーに異なる「サービス」を分離してインストールするために何をすることをお勧めしますか?独自のバージョンの(Perl、python、...)?

以下に解決策を提案しますが、他に選択肢があれば興味があります。

2
VonC

私がこれまでに見つけた唯一の解決策:

  • 複数のアプリケーションのインストール(非rootとして)と互換性があります。
  • 各アプリケーションが独自の依存関係のセットを持つことを許可します(依存関係のセットごとに使用される潜在的な異なるバージョン)

は:

すべてを再コンパイル

(そして、Solarisサーバーにデフォルトでインストールされている/usr/swf/bin/gccは、前提条件のgcc 3.4.6よりも古いため、必要に応じてgcc自体も意味します)

このグローバル再コンパイルで使用されるすべてのバージョンは、 sunfreeware からのものであり、必要なすべての依存関係の詳細が示され、各パッケージのソースへのリンクが提供されます。
これはLinuxとSolarisの両方で機能します。

各パッケージソースはダウンロードされ、コンパイルされ、$HOME/usr/localにインストールされます(つまり、システムパスにnot)。
重要なのは、.bashrcまたは/usr/binを持たないようにするために、$ PATHを変更する/usr/local/binを持つことです。その中にありますが、$HOME/usr/local/binのみです。


私は時間をかけて見つけましたいくつかの利点

  • /usrのライブラリは変更される可能性があり、現在実行されているいくつかのサービスに影響はありません($HOME/usr/localにインストールされている独自の依存関係のセットですべてコンパイルされているため)
  • コンパイルされたアプリケーションを実行する非rootユーザーは、自分の環境ではほとんどrootであり、そのユーザーは$HOME/usr/local内の任意の要素を起動/強制終了/更新/再コンパイルできます。
  • $HOMEに新しいディレクトリを作成し、特定のアプリケーションのアップグレードをテストするためにすべての依存関係を再コンパイルするのは簡単です。最終的に同じパッケージの複数のバージョンが作成され、あるバージョンから別のバージョンにテスト/切り替えられる可能性があります。
  • コンパイルオプションを制御し、必要に応じてallモジュールをアクティブにしてApache Httpdをコンパイルするのは非常に簡単です(事前にコンパイルされたパッケージとは対照的に、あなたが得る)。

主な欠点は次のとおりです。

  • 完全なコンパイルには時間がかかる場合があります(Linuxでは最大1時間、Solarisでは3〜4時間)。
    しかし、必ずしもすべてを再コンパイルする必要はありません。
  • コンパイルオプションはパッケージごとに異なり、適切に設定するには非常に複雑になる可能性があります
  • 環境変数(LDFLAGSCFLAGSCPPFLAGSLD_LIBRARY_PATH)は、適切な値で設定するのが難しい場合があります
  • 適切な依存関係を抽出してコンパイルを起動できるスクリプトがない場合は、手動プロセスを意味します。これはドラッグです。
    (私はそのスクリプトを作成中であり、GitHubで公開します)
4
VonC

すべてのサービスにchroot環境をセットアップし、その下にそれらのパッケージをインストールするオプションがあります。基本的に多くのライブラリをchroot環境に複製する必要があるという点で、それは確かにいくらかの肥大化を伴います。ただし、サービスを他のすべてのサービスから分離し、その逆も同様であり、環境を完全に(ルートのように)制御できます。

これには、chroot環境をセットアップしてアクセスするためにrootアクセスが必要です。

後続のアクセスは、たとえばを使用して管理できます。 SSH:

http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229

2
Andrei Sosnin

Solarisでは、$ Originマジックワードを使用してRPATHを定義できます。たとえば、次のレイアウトがある場合、バイナリのRPATHでRPATHを「$ Origin /../ lib」として定義し、-Rフラグをリンカに渡すことができます。

/usr/local/bin/foo
/usr/local/lib/libfoo.so.1

ただし、ユーザーがレイアウトを指定した場合は機能しません。たとえば、ユーザーはbindirを/ usr/local/bin/sparcv9に設定し、libdirを/ usr/local/lib/sparcv9に設定できます。この場合、設定は$ Origin /../../ lib/sparcv9である必要があります。

従来、Solaris用にコンパイルされたすべてのバイナリはハードコードされたRPATHを使用するため、再配置できません。

もう1つ注意すべき点は、 crle です。これにより、動的リンカーを構成できます。

0
automatthias