Repackaging RPMs

Question

Estamos usando o HP DataProtector para o nosso ambiente de backup. O método de instalação deixa algo a desejar, e estamos tentando automatizá-lo de tal maneira que nossos administradores Unix se sintam menos frequentemente. Somos uma loja do SLES / OpenSUSE, então estamos tentando criar um repositório do YUM com os patches do DP.

Eu posso fazer o repo muito bem, é só que os patch RPMs não estão configurados corretamente. O campo 'Revision' no RPM não está definido corretamente, eles são todos "1" mesmo que o RPM mestre que eu tirei esteja corretamente incrementando.

Eu realmente gostaria de poder reconstruir esses RPMs com a Revisão correta, já que isso permitiria que o processo de atualização normal lidasse com esses patches em vez da maneira estranha pela qual a HP deseja lidar com eles.

A maneira estranha que a HP quer lidar com isso exige:

• Configurando um servidor de instalação com todo o software. Não tem problema.
• Permitindo que root ssh em estações cliente para instalar software que afeta a configuração xinitd
  • O que, por sua vez, exige que uma chave pública SSH sem senha seja colocada em todas as máquinas de destino, para que o processo de instalação possa ser remoto em nenhum prompt.
  • Antes que qualquer implementação possa ser feita, cada cliente deve ser manualmente SSHed para raiz no servidor de repo, a fim de preencher known_hosts

Como não permitimos root logins via SSH, toda vez que recebemos um patch, precisamos tocar no sshd_config de cada servidor para permiti-los temporariamente. Também provamos que após a instalação inicial, as correções subseqüentes podem ser instaladas via rpm apenas peachy. Então, gostaríamos de colocar isso em um repositório do YUM, se possível.

    

Answer 1

Em vez de re-empacotar o RPM existente, inspirado pela HP, empacotei-o em um RPM adicional. O novo RPM é muito simples, pois tem apenas o único patch-RPM dentro dele e invoca o comando rpm para instalá-lo.