Tente criar uma entrada em / etc / hosts
127.0.0.1 localhost.localdomain localhost puppet
remova o argumento --server para o comando do agente fantoche.
Instalei o mestre e o agente de marionetes na mesma máquina. Quando o cliente é iniciado, recebi a seguinte mensagem de erro.
puppet agent --server=agent.com --no-daemonize --debug
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client
Descubra o FQDN do seu puppetmaster emitindo:
# openssl x509 -noout -subject -in /var/lib/puppet/ssl/ca/ca_crt.pem
subject= /CN=Puppet CA: host.domain.com
Compare com a saída (se houver) de:
# puppet cert list --all
Adicione uma entrada ao seu arquivo /etc/hosts apontando o IP escutando na puppetmaster port ( 8140 ):
192.168.124.2 host.domain.com host
Para descobrir qual IP usar, você precisa conhecer o processo de escuta, que é diferente se for uma instalação autônoma de puppetmaster ou apache + passenger . Você pode usar:
netstat -an | grep 8140.*LISTEN
Verifique seu arquivo /etc/puppet/puppet.conf , especificamente a entrada server= , que deve estar apontando para o FQDN descrito acima.
Não use localhost , a menos que você não queira que puppetmaster seja encontrado.
Antes de iniciar o pupppet agent , problema:
# puppet agent --test --waitforcet 2
que instrui o agente a enviar um CSR para o CA dos maestros e esperar que ele seja assinado.
Verifique usando
# puppet cert --list
O pendente para assinar o CSR. Assine:
# puppet cert sign host.domain.com
Assista ao agente fantoche receber um catálogo compilado e aplicá-lo. Depois disso, você está pronto para iniciar o agente e adicioná-lo aos scripts de inicialização.
Descobri que ter o seguinte conjunto em /etc/puppet/puppet.conf para resolver um caso em que a regeneração de certs "pelo livro" ainda produzia a situação descrita no Q:
[master]
certname=masterhost.domain.com
[agent]
certname=agenthost.domain.com
(onde masterhost.domain.com é o FQDN do puppetmaster e agenthost.domain.com o mesmo para o agente)
IMO é uma maneira bastante clara de garantir que o fantoche saiba qual nome é para o mestre e qual é para o agente no caso de ter ambos executados no mesmo host, especialmente porque ter definido apenas server=masterhost.domain.com não parecia ser o suficiente para evitar conflitos.
Não encontrei a solução proposta de adicionar o DN do mestre de fantoches em /etc/hosts (já o tinha como um alias de DNS), por isso não posso dizer se isso teria ajudado no meu caso.