Cache do cliente Puppet, mas não atualizando fatos locais

Question

Eu tenho um servidor pmaster-dev que é um cliente de marionetes (seu mestre é pmaster ). O servidor pmaster-dev funciona como um mestre de marionetes para vários clientes.

Quando o pmaster-dev faz check in com pmaster , ele armazena em cache seus fatos em um arquivo de banco de dados sqlite3 local /var/lib/puppet/state/clientconfigs.sqlite . Em cada check-in subseqüente, o pmaster-dev nunca atualiza este cache local. Assim, seus fatos são sempre obsoletos. Outros clientes do pmaster (incluindo o próprio pmaster ) nunca armazenam em cache.

Como podemos informá-lo para atualizar o cache ou desabilitar o cache dos fatos? Por que é cache enquanto outros clientes do pmaster não são?

Estamos rodando 2.7.18 em um sistema squeeze Debian.

Aqui está o arquivo /etc/puppet/puppet.conf para pmaster-dev :

[agent]
server = pmaster.example.org
environment = master
configtimeout = 300

logdir = /var/log/puppet
vardir = /var/lib/puppet
ssldir = /etc/puppet/ssl
rundir = /var/run/puppet

ca_server = puppetca.example.org
ca_port = 8141

graph = true
report = true
pluginsync = true

classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
diff_args = '-u'
show_diff = true


[master]
certname = pmaster-dev.example.org
syslogfacility = local2

logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run/puppet
ssldir = /srv/puppetmaster/ssl

reports = tagmail,lastcheck,logcache
manifest = /srv/puppet/$environment/manifests/site.pp
graph = true
modulepath = /srv/puppet/$environment/modules:/srv/puppet/$environment/services:/srv/puppet/$environment/clients
cacrl = /srv/puppetmaster/ssl/crl.pem
ca = false

manifestdir = /srv/puppet/$environment/manifests
queue_source = stomp://pupqueue-dev.example.org:61613/
async_storeconfigs = true
storeconfigs = false
dbadapter = mysql
dbuser = puppet
dbpassword = secret
dbserver = pupqueue-dev.example.org
dbname = puppet

ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

    

Answer 1

Depois de cavar alguns arquivos fonte do Puppet Ruby, eu rastreei o problema em um bug onde há uma conflação das seções do arquivo de configuração do Puppet. Tudo se resume à palavra "mestre"

Resumo : Os mestres de marionetes que atuam como clientes de marionetes e no ambiente "mestre" causam problemas com o arquivo de configuração análise.

Detalhes : Quando o agente fantoche inicia uma das coisas que ele faz é analisar o arquivo de configuração (normalmente /etc/puppet/puppet.conf ).

O arquivo de configuração é dividido em seções, por exemplo, "[main]", "[agent]", "[master]", etc. Cada uma dessas seções é armazenada separadamente no hash gerado a partir da análise do arquivo de configuração . No meu caso, o pmaster-dev tem estas seções: "memory", "master", "cli" e "agent".

Também pode haver seções por ambiente. Por exemplo, se houver um ambiente chamado "stable201301", pode haver uma seção no arquivo de configuração intitulada "[stable201301]".

Para cada uma das seções acima (chamadas "fontes" no código), você examina todas as configurações que associaram "ganchos". Se nessa seção a definição com um gancho for definida, você chamará o gancho dessa configuração. Algumas das configurações que possuem ganchos incluem catalog_format, node_name_fact e storeconfigs.

Uma das configurações mais interessantes é "async_storeconfigs", que tem um gancho que configura uma classe de cache.

Lembre-se de que as seções também podem incluir aquelas para cada ambiente. O PROBLEMA: E se o mestre Puppet (quando atuando como um cliente Puppet) estiver no ambiente "master"?

O papel usual da seção "[master]" é para configurações de um mestre de marionetes. Mas se o próprio mestre dos fantoches estiver usando o ambiente "mestre", teremos um conflito. Em particular, a configuração "async_storeconfigs" do "[master]" é carregada a partir do arquivo de configuração. Como o mestre Puppet (como cliente Puppet) está no ambiente "master", essa configuração faz com que a classe de cache seja definida e, assim, quando puppet agent --test é executado, o cliente de marionetes procura fatos em cache.

Solução (?) : Você pode ter certeza de que um mestre de marionetes nunca usou o ambiente "mestre". Uma solução melhor seria fazer com que o analisador de configuração do cliente não olhasse para a seção "[master]" (já que isso é aplicável apenas aos mestres do Puppet). Uma solução ainda melhor seria separar os arquivos de configuração do cliente e do mestre por completo.

    

Answer 2

Parece que você está confuso sobre o que é realmente clientconfigs.sqlite . Este arquivo é parte do mecanismo Stored Configuration do Puppet. É um arquivo mantido pelo Puppet Master, não pelos clientes.

Sua criação é controlada pelos parâmetros storeconfigs , async_storeconfigs e db* na seção [master] de puppet.conf . O padrão (quando nenhum parâmetro db* está definido) é usar o adaptador SQLite.

A partir da configuração que você colou, parece que você configurou o master para armazenar a configuração dentro de um banco de dados MySQL através de um broker Stomp. Então parece que não atualizar o banco de dados SQLite é por design?

Por que esse arquivo de banco de dados foi criado para começar é uma boa pergunta. Minha hipótese seria que o Puppet Master começou com uma configuração incompleta durante a configuração inicial do servidor.