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

синхронизировать систему rpmdb с локальной копией

На наших бизнес-серверах по разным причинам мы хотим использовать пакеты rpm, но мы не можем установить пакет rpm в системную базу данных (разрешения, несколько экземпляров и т. Д.). Итак, мы создали нашу собственную локальную rpmdb и устанавливаем пакеты без полномочий root и с аргументом --dbpath. Таким образом, в настоящее время в нашей локальной базе данных может быть только 10 пакетов. Это хорошо работает, допускает установку без полномочий root и позволяет использовать несколько экземпляров одного и того же пакета, поскольку используются несколько rpmdb. Недостатком является то, что все должно быть установлено с --nodeps, потому что наши локальные базы данных не видят никаких пакетов, установленных на системном уровне.

В попытке решить проблему --nodeps есть несколько способов инициализировать свои локальные базы данных с помощью текущей системной базы данных (например, просто скопировать / var / lib / rpm / Packages и перестроить). Затем установка наших пакетов приложений поверх должна позволить нам полностью использовать зависимости. Но проблема в том, как сохранить синхронизацию системных пакетов после первой копии. Если администраторы устанавливают системный патч, обновляется только системная rpmdb. Я ищу какой-то способ написать ночное пакетное задание, которое будет сравнивать обновления и применять обновления базы данных только к нашим локальным копиям.

Есть мысли о том, какие команды можно использовать для этого?

Спасибо за любую помощь. Брайан

--nodeps, перемещаемые пакеты и ручное управление Berkeley DB болезненно. И вы хотите сделать все три? Я не рекомендую это делать, это на 20 лет назад в управлении пакетами. Очень немногие пакеты из Fedora или EL могут быть перемещены, так как yum просто не может справиться с этим. Кроме того, nodeps означает, что вы можете попасть в зависимости, которые не легко исправить с помощью yum.


Предоставьте пользователям «хост» для каждого необходимого им экземпляра. ВМ, контейнеры, chroot (yum --installroot), любой из них может быть дешевле, чем время на борьбу с RPM.

Автоматическая подготовка. Имейте процедуры, в которых пользователи могут предлагать изменения в наборе пакетов, которые будут своевременно рассмотрены. Возможно, дайте некоторым пользователям привилегию тестировать экземпляры, чтобы они могли пробовать что-то, не нарушая ничего важного.

Переупакуйте что-нибудь, чтобы не требовать перемещения или альтернативного rpmdb. Переходите к неконфликтным путям, создавайте отдельные пакеты с номерами версий в имени. В общем, следуйте рекомендациям по упаковке пакетов Fedora RPM. Затем пакетами можно управлять с помощью yum.