Estou escrevendo alguns RPMs que instalam arquivos de configuração do repositório YUM para vários repositórios internos do YUM, mesma estrutura e conceito que os RPMs do repositório EPEL.
Teremos vários ambientes com repositórios equivalentes, portanto, usamos o plug-in de prioridades do yum para garantir que as repos de ambiente anteriores na sequência de implementação (ou seja, QA) tenham prioridade sobre as que vêm depois (ou seja, Produção). Também estamos replicando as versões do CentOS que usamos em um espelho interno. Temos tudo isso funcionando, incluindo a publicação desses RPMs de configuração de repo, mas temos um caso especial restante em que eu gostaria de alguns conselhos sobre a melhor maneira de lidar com um problema de design.
E isso é: O arquivo de configuração do repositório de base do CentOS /etc/yum.repos.d/CentOS-Base.repo é de propriedade do RPM centos-release, então não posso sobrescrevê-lo em meu próprio RPM sem substituir este RPM do sistema, o que não quero fazer. Mas, preciso fazer algumas alterações nesse arquivo para que ele funcione com o design descrito acima. Em cada seção de recompra,
Eu preciso alterar essas linhas:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os e #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
Para essas linhas:
mirrorlist=http://mirrorlist.MYCOMPANY.com/?platform=centos&release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.MYCOMPANY.com/centos/$releasever/os/$basearch/ e priority=2
Atualmente, estou criando um RPM que instala o /etc/yum.repos.d/CentOS-Base-pr.repo e, em% post, ele renomeia o CentOS-Base.repo existente para o CentOS-Base.repo. orig, em seguida, renomeia o novo CentOS-Base-pr.repo para CentOS-Base.repo. No% postun, ele inverte isso para restaurar o arquivo original. Eu sinto que isso funciona, mas é um pouco chocante.
O que eu gostaria de fazer em vez disso, é instalar nenhum arquivo, mas executar um script sed para fazer essas alterações no arquivo CentOS-Base.repo original no% post, e outro script sed para reverter as alterações no % postun. Isso me permite lidar com a instalação / desinstalação de todos os nossos repositórios personalizados da mesma maneira, com um resultado consistente para os repositórios existentes e novos.
O que eu não sei é - essa é uma abordagem válida ou recomendada quando você está tentando fazer esse tipo de configuração "ajustes" em arquivos existentes instalados por outros RPMs?
Antes de obter respostas para esse efeito, estamos usando o Chef para a maioria das configurações pós-RPM, mas não queremos usá-lo nesse caso, já que não queremos ter um caso especial repo config em apenas uma instância, e estamos tentando usar RPMs para encapsular a lógica de instalação / atualização "pesada" dentro dos RPMs em outros lugares. Queremos que nosso próprio software se comporte como qualquer outro software de código aberto, pois ele pode ser instalado e executado sem dependência do Chef para instalação básica, e o Chef é usado apenas para personalização (ou seja, como o Chef configura o nginx ou tomcat).
Agradecemos antecipadamente por qualquer conselho ...
Não há problema em usar um script sozinho ou um script incorporado em uma rpm, se essa for sua preferência. Eu gosto da idéia de usar vazio ou meta rpm para criar seus próprios grupos virtuais ou fazer certas tarefas. Neste caso, eu ficaria preocupado com o fato de que um pacote posterior de lançamento de centos iria acabar com o meu troco. Isso seria mais fácil se o pacote tivesse o arquivo desejado e você o instalasse com a opção --replacefiles .