На наших бизнес-серверах по разным причинам мы хотим использовать пакеты rpm, но мы не можем установить пакет rpm в системную базу данных (разрешения, несколько экземпляров и т. д.). Поэтому мы создали нашу собственную локальную базу данных rpm и устанавливаем пакеты как некорневой пользователь и с аргументом --dbpath. Поэтому в настоящее время в нашей локальной базе данных может быть только 10 пакетов. Это хорошо работает, позволяет выполнять установку некорневого пользователя и позволяет использовать несколько экземпляров одного и того же пакета, поскольку используется несколько баз данных rpm. Недостаток в том, что все должно быть установлено с --nodeps, поскольку наши локальные базы данных не видят ни одного из пакетов, установленных на системном уровне.
В попытке решить проблему --nodeps есть несколько способов, которыми я могу инициализировать свои локальные базы данных с текущей системной базой данных (например, просто скопировать /var/lib/rpm/Packages и перестроить). Затем установка наших пакетов приложений поверх должна позволить нам полностью использовать зависимости. Но проблема в том, как поддерживать синхронизацию системных пакетов после первого копирования. Если администраторы установят системный патч, будет обновлен только системный rpmdb. Я ищу какой-нибудь метод для написания ночного пакетного задания, которое будет сравнивать обновления и применять только обновления базы данных к нашим локальным копиям.
Есть ли у вас мысли, какие команды можно использовать для этого?
Спасибо за любую помощь. Брайан
решение1
--nodeps, перемещаемые пакеты и ручное управление Berkeley DB — все это болезненно. И вы хотите сделать все три? Я не рекомендую этого, это возврат на 20 лет назад в управлении пакетами.Очень немногие пакеты из Fedora или EL можно переместить., так как им просто нельзя управлять с помощью yum. Кроме того, nodeps означает, что вы можете попасть в зависимости, которые нелегко исправить с помощью yum.
Дайте пользователям «хост» для каждого нужного им экземпляра. Виртуальные машины, контейнеры, chroot ( yum --installroot), любой из них может обойтись дешевле, чем время, потраченное на борьбу с RPM.
Автоматизируйте подготовку. Имейте процедуры, в которых пользователи могут предлагать изменения в наборе пакетов, которые будут рассмотрены своевременно. Возможно, предоставьте некоторым пользователям привилегию тестировать экземпляры, чтобы они могли пробовать что-то, не ломая ничего важного.
Перепакуйте все, чтобы не требовалось перемещение или альтернативная rpmdb. Переместите на неконфликтующие пути, создайте отдельные пакеты с номерами версий в Name. В общем, следуйте рекомендациям по упаковке Fedora RPM. Затем пакетами можно управлять с помощью yum.