En nuestros servidores comerciales, por varias razones queremos usar paquetes rpm, pero no podemos instalar el paquete rpm en la base de datos del sistema (permisos, instancias múltiples, etc.). Así que hemos creado nuestro propio rpmdb local e instalamos paquetes como no root y con un argumento --dbpath. Por lo tanto, actualmente nuestra base de datos local puede tener solo 10 paquetes. Esto funciona bien, permite una instalación no root y permite múltiples instancias del mismo paquete porque se utilizan múltiples rpmdbs. El inconveniente es que todo debe instalarse con --nodeps porque nuestras bases de datos locales no ven ninguno de los paquetes instalados a nivel del sistema.
En un intento de resolver el problema de --nodeps, hay varias maneras en que puedo inicializar mis bases de datos locales con la base de datos del sistema actual (simplemente copie /var/lib/rpm/Packages y reconstruya, por ejemplo). Luego, instalar nuestros paquetes de aplicaciones en la parte superior debería permitirnos utilizar las dependencias por completo. Pero el problema es cómo mantener sincronizados los paquetes del sistema después de la primera copia. Si los administradores instalan un parche del sistema, solo se actualizará el rpmdb del sistema. Estoy buscando algún método para escribir un trabajo por lotes nocturno que compare las actualizaciones y aplique las actualizaciones de la base de datos únicamente a nuestras copias locales.
¿Alguna idea sobre qué comandos podrían usarse para lograr esto?
Gracias por cualquier ayuda. brian
Respuesta1
--nodeps, los paquetes reubicables y la administración manual de la base de datos Berkeley son dolorosos. ¿Y quieres hacer los tres? No recomiendo esto, es retroceder 20 años en la gestión de paquetes.Muy pocos paquetes fuera de Fedora o EL son reubicables, ya que simplemente no puede ser administrado por yum. Además, los nodeps significan que puede entrar en dependencias que yum no puede solucionar fácilmente.
Ofrezca a los usuarios un "host" para cada instancia que necesiten. VM, contenedores, chroots ( yum --installroot), cualquiera de estos puede resultar menos costoso que luchar contra RPM.
Automatizar el aprovisionamiento. Tenga procedimientos donde los usuarios puedan proponer cambios en el conjunto de paquetes que se revisen de manera oportuna. Posiblemente otorgar a algunos usuarios privilegios para probar instancias, para que puedan probar cosas sin romper nada importante.
Vuelva a empaquetar cualquier cosa para que no requiera reubicación o rpmdb alternativo. Vaya a rutas que no entren en conflicto, cree paquetes separados con números de versión en Nombre. En general, siga las pautas de empaquetado de Fedora RPM. Entonces los paquetes se pueden gestionar con yum.