Marioneta: ¿El nombre del nodo parece depender del dns inverso?

Parece que me encuentro con un pequeño problema para entender cómo hacer que esto funcione. Tengo un nuevo servidor que estoy construyendo, sentado detrás de la oficina NAT en el trabajo, con sus mapas DNS inversos office.mydomain.com, pero quiero que la máquina sea ns2.mydomain.compor el bien de la marioneta.

Fragmento de node.pp:

node 'ns2.mydomain.com' inherits basenode {
  info('ns2.mydomain.com')
}

node 'office.mydomain.com' inherits basenode {
  info('office.mydomain.com')
}

Y mi 'puppet.conf' en el cliente:

[main]
#was node_name=ns2.mydomain.com
#was fqdn=ns2.mydomain.com
certname=ns2.mydomain.com
node_name=cert

Mi syslog en el servidor informa:

Sep 16 22:59:12 support puppetmasterd[2800]: Host is missing hostname and/or domain: office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: (Scope(Node[office.mydomain.com])) office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: Compiled catalog for office.mydomain.com in 0.03 seconds
Sep 16 22:59:12 support puppetmasterd[2800]: Caching catalog for ns2.mydomain.com

¿Cómo puedo hacer que tome la configuración ns2.mydomain.comsin hacer algo como esto:

node 'ns2.mydomain.com' inherits basenode {
  info('ns2.mydomain.com')
}

node 'office.mydomain.com' inherits 'ns2.mydomain.com' {
  info('office.mydomain.com')
}

ACTUALIZACIÓN : Este problema parece estar causando otros problemas también. Por ejemplo, si info("$fqdn")mientras la máquina está sentada, office.mydomain.comel hecho de fqdn está vacío, así como el $operatingsystem. Es casi como si los hechos no se descubrieran correctamente. ¿Hay quizás un problema de NAT? ¿Hay alguna sugerencia para localizar esta causa de este problema?

puppet

— Gnarf
fuente

Respuestas:

Aaah, detección de nombre de host de Puppet. Qué pesadilla...

Por defecto, qué nombre se usará para encontrar qué nodedefinición usar se basa en el contenido del hecho fqdn. Lo que realmente se asigna depende de algunas cosas diferentes, y sí, el DNS inverso es uno de ellos, ¡y se prefiere sobre el propio nombre de host de la máquina!

Sin embargo, este nombre (generalmente) solo se aplica en el momento de generación del certificado. En realidad, está haciendo un mal uso de la node_namevariable: debe establecerse en uno de 'cert' o 'facter'. El fqdnparámetro también está en desuso.

Lo que realmente quiere hacer es establecer el certnameparámetro en el cliente para el nombre del nodo que desea utilizar, a continuación, establezca node_namea cert(o simplemente dejarlo fuera, ya que certes el valor por defecto). Esto tomará el nombre del nodo del CN del certificado que presenta el cliente, y el certnameparámetro se asegura de que esté configurado en algo razonable en lugar de cualquier factor que decida inventar por sí mismo. Desafortunadamente, dado que ya ha creado certs "incorrectos", necesitará regenerar esos certs ( rm -rf /var/lib/puppet/sslen el cliente y volver a ejecutar Puppet) después de haber configurado la configuración, para que se creen y usen los certs correctos.

Si todo esto suena un poco complicado, tienes razón, lo es. Bienvenido a Puppet.

— womble
fuente

Hola - así mirando titiritero y marioneta - ambos han node_name=cert, actualizado cert_name=ns1.mydomain.comy facter fqdnvuelve ns1.mydomain.comen el cliente pero todavía estoy terminando con los mismos mensajes de error relacionados office.mydomain.com.

— gnarf

re: certname, tienes razón, me acordé mal y no revisé los documentos como debería haberlo hecho. En cuanto a la falta de fijación, debe regenerar el certificado del cliente; He actualizado mi respuesta para cubrir eso.

— womble

En realidad, mi archivo cert es ns1.mydomain.com.pemy su CN también es ns1 ... Eso es "correcto" ¿verdad? office.mydomain.comes lo que está usando como su nombre de nodo, y aparentemente cada vez que intenta obtener datos al analizar, en lugar de usar el nombre del certificado como nombre de nodo. Tal vez me estoy perdiendo algo más? Ninguno de mis hechos parecen ser transmitida a través del analizador o bien info($fqdn)sólo demuestra una línea vacía en el ámbito puse en.

— gnarf

No sé lo que has hecho, pero te las arreglaste para hacer algo realmente bueno. Creo que estás solo.

— womble

Otra actualización: logré obtener todas las cosas "preconfiguradas" desde detrás del lan de la oficina y poner en funcionamiento el nuevo servidor de nombres, tan pronto como comenzó a usar el DNS inverso correcto, todos los hechos aparecieron correctamente ...

— gnarf

Parece que estoy teniendo buena suerte (aunque todavía hay algunos casos de prueba que quiero ver) en la edición /etc/hostspara enumerar el fqdn deseado en 127.0.0.1 como la primera opción. Parece estar detectándolo correctamente / pasando hechos entonces. Aunque parece que todavía necesito crear un nodo llamado office.mydomain.comque herede el nodo que quiero.

— Gnarf
fuente

Esto funcionó para mí. (tenía que quitar el directorio SSL como se mencionó anteriormente)

— bwizzy

Esto también funcionó bien para mí, y también está respaldado por la documentación de Puppet: puppetlabs.com/blog/resolving-dns-issues

— DuffJ