Soy nuevo en la marioneta, pero lo estoy recogiendo rápidamente. Hoy en día, estoy corriendo en un problema al intentar ejecutar el siguiente:Agente de marionetas no puede encontrar el servidor

$ puppet agent --no-daemonize --verbose --onetime 

**err: Could not request certificate: getaddrinfo: Name or service not known 
Exiting; failed to retrieve certificate and waitforcert is disabled**

Parecería que el agente no sabe qué servidor se conecte a. Podría simplemente especificar --server en la línea de comandos, pero eso no me servirá cuando esto se ejecute como daemon en producción, así que en su lugar, especifico el nombre del servidor en /etc/puppet/puppet.conf como lo siguiente:

[main] 
    server = puppet.<my domain>

me hago tienen una entrada DNS para puppet.<my domain> y si dig puppet.<my domain>, veo que el nombre se resuelve correctamente.

Toda la documentación de títeres que he leído indica que el agente intenta conectarse a un maestro de marionetas al puppet de manera predeterminada y sus opciones son el truco del archivo de host o hacer lo correcto, crear un CNAME en DNS y editar el puppet.conf en consecuencia, lo que he hecho.

Entonces, ¿qué es lo que me falta? ¡Cualquier ayuda es muy apreciada!

Fuente

2012-05-23 Kent Rancourt

Jugando con esto más, estoy comenzando a preguntarme si puppet.conf siquiera se lee cuando se ejecuta en esta casa solariega. Puse basura en puppet.conf e incluso intenté borrarla y tampoco parece afectar los resultados cuando el agente se ejecuta desde la línea de comandos. Sin embargo, impide el inicio y el apagado limpios cuando se ejecuta como un servicio. ¿Podría ser así de simple? –

D'oh! ¡Necesito sudo para hacer esto! Entonces todo funciona.

Fuente

2012-05-24 03:13:39

Ah, cuando no estés usando sudo, Puppet solo leerá ~/.puppet/puppet.conf en lugar de /etc/puppet/puppet.conf. Puppet se puede ejecutar sin privilegios de root, pero obviamente no puede instalar paquetes de sistema ni administrar servicios, etc. –

Me sorprendió demasiado. Gracias :) –

Una pequeña nota. Cuando Puppet se instala con un usuario especial como 'puppet' en CentOS, debe ejecutarlo con ese usuario y proporcionar el parámetro' --server' de la siguiente manera: 'sudo -u puppet puppet agent --server = puppet.my-domain .com' –

De hecho, tuve el mismo error pero estaba usando los dos Learning Puppet vm e intento ejecutar el comando 'puppet agent --test'.

He resuelto el problema abriendo el archivo/etc/hosts en tanto el principal y el agente de VM y la línea

***.***.***.*** learn.localdomain learn puppet.localdomain puppet

la dirección IP (los asteriscos) era originalmente un número aleatorio. Tuve que cambiar este número en ambos vm para que fuera la dirección IP del nodo maestro.

Supongo que para usuarios experimentados mi consejo es verificar el archivo/etc/hosts para asegurarse de que las direcciones IP aquí para el maestro y el agente no solo coincidan, sino que sean las mismas que la dirección IP del maestro.

para otros noobs como yo, mi consejo es leer la documentación más claramente. Este fue un paso en el proceso de 'creación de una máquina virtual agente de' la estoy totalmente echado de menos xD

Fuente

2013-07-02 16:55:36 scottyseus

tuve que usar el --server bandera:

sudo puppet agent --noop --server=puppet.example.org

Fuente

2013-10-15 21:50:33 bmaupin

En mi caso, yo estaba recibiendo el mismo error, pero fue debido al certificado que debe haberse firmado en el nodo en el servidor de Puppetmaster.

para comprobar certs pendiente ejecutar después de:

lista cert títere

"node.domain.com" (SHA256) 8D: E5: 8A: 2 *******"

firmar el certificado de nodo:

títere CERT firmar node.domain.com

Fuente

2016-05-09 14:34:35

tenían el mismo problema hoy en puppet 2.6 en CentOS 6.4 Todo lo que hice para resolver el problema fue verificar las cosas habituales, como hosts y resolv.conf para asegurarse de que eran como se esperaba (en comparación con un servidor que funciona) y luego;

Eliminado/var/lib/títere directorio rm -rf /var/lib/puppet
Se borra el certificado en el titiritero puppetca --clean servername
reiniciado la red service network restart
Re-ran títere

pesar de que el resolv .conf era idéntico al servidor de trabajo, el títere actualizó resolv.conf e inmediatamente volvió a firmar el certificado y reemplazó todos los archivos lib de títere.

Todo estaba bien después de eso.

Fuente

2016-08-22 09:26:07

Agente de marionetas no puede encontrar el servidor

Respuesta

lista cert títere

títere CERT firmar node.domain.com

Cuestiones relacionadas