%20%22....%20existe%20y%20no%20es%20el%20repositorio%20deseado%22..png)
Utilizo Puppet/Vcsrepo para distribuir y actualizar software a un grupo de servidores Linux desde un servidor Bitbucket (nube). Esto funcionó bien durante años, pero hace aproximadamente 6 meses, Puppet comenzó a quejarse de cada repositorio Error: Path /usr/local/tools/... exists and is not the desired repository.
en cada ejecución. Creo que el problema pudo haber comenzado cuando pasamos de la versión local de Bitbucket a la versión en la nube.
Si elimino la ruta y ejecuto Puppet, reemplaza el directorio y luego vuelve a vomitar en la siguiente ejecución. Terminé eliminando los repositorios cada vez que necesito actualizarlos.
El código de la marioneta se ha simplificado a:
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,
}
Alguna idea de cuál es el problema o cómo diagnosticarlo.
Respuesta1
Sí, un parche CVE para giten bancarrotasu configuración existente. Esto se lanzó en Debian Buster en los últimos días, lo que provocó una falla en el sistema Puppet (5.5.10-4). No parece haber un parche disponible para vcsrepo 3.2.1, el último compatible con Puppet 5. No estoy seguro de por qué mis máquinas Bullseye no parecen verse afectadas.
Si puede actualizar a Puppet 6, la versión actual de vcsrepo se encargará de esto.
Si no, como solución alternativa, puedes hacer:
una vez:
concat { '/etc/gitconfig' :
owner => 'root',
group => 'root',
mode => '0644',
}
y luego en tu definición dentro de cada bucle:
concat::fragment { "gitconfig_$repo" :
target => '/etc/gitconfig',
content => "[safe]\n\tdirectory = /usr/local/tools/$repo\n\n",
before => Vcsrepo["/usr/local/tools/$repo"],
}