Trabalhando com um repositório YUM customizado

Question

Eu tenho um monte de ferramentas (nagios, munin, fantoche, etc ...) que são instaladas em todos os meus servidores. Eu estou no processo de construir um repositório yum local. Eu sei que a maioria das pessoas simplesmente despeja todos os rpms em uma única pasta (dividida no caminho correto) e então executa o createrepo dentro do diretório. No entanto, o que aconteceria se você tivesse que atualizar o rpms?

Eu pergunto porque eu ia lançar cada software em sua própria pasta.

Exemplo um, coloque todos os pacotes dentro de uma pasta (custom_software)

/admin/software/custom_software/5.4/i386
/admin/software/custom_software/5.4/x86_64
/admin/software/custom_software/4.6/i386
/admin/software/custom_software/4.6/x86_64

O que eu estou pensando ...

/admin/software/custom_software/nagios/5.4/i386
/admin/software/custom_software/nagios/5.4/x86_64
/admin/software/custom_software/nagios/4.6/i386
/admin/software/custom_software/nagios/4.6/x86_64
/admin/software/custom_software/puppet/5.4/i386
/admin/software/custom_software/puppet/5.4/x86_64
/admin/software/custom_software/puppet/4.6/i386
/admin/software/custom_software/puppet/4.6/x86_64

Dessa forma, se eu tivesse que atualizar para a versão mais recente do fantoche, posso salvar o gerenciamento dos arquivos de acordo. Eu não saberia quais rpms pertencem a qual software se eu as jogasse em uma pasta grande. Faz sentido?

    

Answer 1

Eu acredito que você precisa de um repositório separado, com dados gerados por createrepo , para cada versão distinta que você está apoiando. É assim que você tem um catálogo que o yum conhece através do seu arquivo .repo. Seu primeiro método proposto permitiria isso.

Usando seu segundo método, você acabaria tendo que criar dados de repositório para cada pacote que estava mantendo, o que parece um pesadelo, tanto quanto você teria que ter dados de repositório para cada pacote.

Além disso, eu não estaria construindo dentro de seu repositório (que é a única razão pela qual eu posso pensar em separá-lo por software). Configure seu ambiente de construção com rpmdev-setuptree (disponível no pacote rpmdevtools ), construa o rpms e copie / mova da estrutura de construção para sua estrutura de repositório ( /<root_repo>/<release>/<arch>/<RPMS/SRPMS> ) e, em seguida, gere seus dados de repositório via createrepo (ou createrepo --update . ) no diretório de lançamento (5.4 / 4.6).

    

Answer 2

Acho que jogá-los todos em uma pasta funciona bem. Quando você tiver uma nova versão de um pacote, coloque-o lá e use "repomanage" do pacote yum-utils para aparar versões mais antigas.

    

Answer 3

Use uma mistura de ambos: Crie Repos de tipos diferentes e jogue as rpms relevantes nelas.

Para cada repo, usamos um variante "staging" que contém os mais novos rpms. Se estes testes forem bem feitos em máquinas de teste, esses rpms serão enviados para os repositórios ao vivo.

Os rpms de preparação podem ser automatizados.

    

Answer 4

Eu tenho tudo englobado em um diretório. Quando uma atualização é lançada, movo o RPM para o diretório e removo o antigo. Então corro createrepo -v --update /PATH/TO/REPO .