Назад | Перейти на главную страницу

Как установить пакеты в Linux или Solaris на пути, отличные от путей по умолчанию?

Под "путем по умолчанию" я подразумеваю "/usr/local"или другие пути, управляемые root (" системные пути ").

Мне нужно установить много пакетов приложений (я имею в виду: svn, httpd, git, perl, python, ...) на некоторых Linux (RedHat) или Solaris (10, в локальные зоны) серверов.

Но:

Я пробовал использовать, например, на Solaris, pkgadd -R чтобы попробовать установить предварительно скомпилированные пакеты по пользовательскому пути (а именно, в домашнем каталоге конкретного пользователя, а не в обычном пути по умолчанию /usr/local/...), но все указанные предварительно скомпилированные пакеты содержат ссылки на другие ресурсы в /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
  ...

Так не пойдет, потому что:

Что бы вы порекомендовали сделать, чтобы изолированно устанавливать разные «службы» на одном сервере (Linux или Solaris), каждый из которых потенциально требует своей собственной версии (perl, python, ...)?

Я предлагаю решение ниже, но если у вас есть другие альтернативы, мне интересно.

Единственное решение, которое я нашел до сих пор:

  • совместим с установкой (как некорневой) несколько приложений,
  • позволяя каждому приложению иметь собственный набор зависимостей (с потенциальными разные версии, используемые от одного набора зависимостей к другому)

является:

перекомпилировать все

(и под всем, я имею в виду даже gcc при необходимости, так как /usr/swf/bin/gcc установленный по умолчанию на наших серверах Solaris, даже старше, чем требуется gcc 3.4.6)

Все версии, используемые в этой глобальной перекомпиляции, происходят из солнечные лучи, в котором будут подробно описаны все необходимые зависимости и будут предоставлены ссылки на источники для каждого пакета.
Это работает как в Linux, так и в Solaris.

Каждый источник пакета загружается, компилируется и установлен в $HOME/usr/local (т.е. не в системном пути).
Ключ в том, чтобы иметь .bashrc (например) который будет изменить $ PATH чтобы не было /usr/bin или /usr/local/bin в нем, но только $HOME/usr/local/bin.

Я нашел со временем несколько преимуществ:

  • Библиотеки в /usr может измениться, это не повлияет на несколько запущенных в настоящее время служб (потому что все они были скомпилированы на собственном наборе зависимостей, установленных в $HOME/usr/local)
  • Пользователь без полномочий root, запускающий скомпилированное приложение, в значительной степени корень в его собственной среде, и этот пользователь может запустить / убить / обновить / перекомпилировать любой элемент внутри $HOME/usr/local
  • Создать новую директорию в $HOME и снова скомпилируйте все зависимости для тестирования обновления данного приложения. Вы можете получить несколько версий одного и того же пакета и тестировать / переключаться с одной версии на другую.
  • Вы управляете параметрами компиляции, и очень легко скомпилировать Apache Httpd с помощью все модули, активируемые в нем, если хотите (в отличие от предварительно скомпилированного пакета, в котором вы берете то, что получаете).

В основные недостатки являются:

  • Любая полная компиляция может занять время (до 1 часа в Linux, от 3 до 4 часов в Solaris).
    Но не всегда нужно все перекомпилировать.
  • Параметры компиляции различны для каждого пакета и могут быть довольно сложными для правильной настройки.
  • Переменные среды (LDFLAGS, CFLAGS, CPPFLAGS, LD_LIBRARY_PATH) может быть сложно настроить с правильными значениями
  • Если у вас нет сценария, способного извлекать для вас нужные зависимости и запускать компиляции, это означает: руководство процесс, который является тормозом.
    (Я в процессе создания этого скрипта и опубликую его на GitHub)

Есть возможность настроить среду chroot для каждой службы и установить эти пакеты под ней. Это, безусловно, вызывает некоторое раздувание, поскольку вам необходимо в основном реплицировать многие библиотеки в среду chroot. Но он изолирует ваши сервисы от всех остальных и наоборот и дает вам полный (как у root-прав) контроль над средой.

Для настройки и доступа к среде chroot по-прежнему требуется root-доступ.

Последующим доступом можно управлять, например, с помощью SSH:

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

В Solaris вы можете определить RPATH с помощью волшебного слова $ ORIGIN. Например, если у вас следующий макет, вы можете определить RPATH как '$ ORIGIN /../ lib' в RPATH ваших двоичных файлов, передав флаг -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, что делает их неперемещаемыми.

Еще одна вещь, на которую стоит обратить внимание, может быть crle, позволяющий настроить динамический компоновщик.