%20%22....%20existe%20e%20n%C3%A3o%20%C3%A9%20o%20reposit%C3%B3rio%20desejado.%22.png)
Eu uso o puppet/Vcsrepo para distribuir e atualizar software para vários servidores Linux a partir de um servidor Bitbucket (nuvem). Isso funcionou bem por anos, mas cerca de 6 meses atrás o Puppet começou a reclamar de todos os repositórios Error: Path /usr/local/tools/... exists and is not the desired repository.
a cada execução. Acho que o problema pode ter começado quando mudamos da versão local do bitbucket para a versão em nuvem.
Se eu excluir o caminho e executar o puppet, ele substituirá o diretório e vomitará novamente na próxima execução. Acabei excluindo os repositórios sempre que preciso atualizá-los.
O código da marionete foi simplificado para:
define deploy(Array $names) {
$names.each |$repo| {
vcsrepo { "/usr/local/tools/$repo":
ensure => present,
provider => git,
user => 'tools',
source => "https://[email protected]/uoa/$repo.git",
}
}
}
.....
$names_list = [
'common-library',
'common-tools'
]
...::deploy {"base-tools":
names => $names_list,
}
Alguma ideia de qual é o problema ou como diagnosticar o problema.
Responder1
Sim, um patch CVE para gitquebradosua configuração existente. Isso foi lançado no Debian Buster nos últimos dias, causando falhas no system puppet (5.5.10-4). Não parece haver um patch disponível para vcsrepo 3.2.1, o mais recente com suporte ao Puppet 5. Não sei por que minhas máquinas Bullseye não parecem ter sido afetadas.
Se você puder atualizar para o Puppet 6, a versão atual do vcsrepo cuidará disso.
Caso contrário, como solução alternativa, você pode fazer:
uma vez:
concat { '/etc/gitconfig' :
owner => 'root',
group => 'root',
mode => '0644',
}
e então na sua definição dentro de cada loop:
concat::fragment { "gitconfig_$repo" :
target => '/etc/gitconfig',
content => "[safe]\n\tdirectory = /usr/local/tools/$repo\n\n",
before => Vcsrepo["/usr/local/tools/$repo"],
}