cfengine 3 políticas de atualização lenta para clientes

Question

Meu problema: as políticas cfengine3 são criadas / atualizadas manualmente no servidor (hub de políticas) e os clientes regularmente (a cada ~ 5 minutos) os removem do servidor: / var / cfengine / masterfiles para seus respectivos someclient: / var / cfengine / inputs (como deveriam).

Mas isso se comporta de maneira inconsistente algumas vezes . Um arquivo atualizado no servidor pode não ser refletido nos clientes até um bom tempo depois. Pode ser > 30 minutos ou mais até que de repente "veja" a atualização. Isso acontece especialmente se o que eu criei / atualizei estiver em um subdiretório sob ./masterfiles.

Eu verifiquei com o tcpdump que cada cliente está de fato se comunicando com o servidor mestre através da porta cfengine (5308) a cada 5 minutos.

Não consigo ver o motivo pelo qual os arquivos de política não são atualizados.

Alguém já experimentou o mesmo ou tem uma sugestão? Obrigado.

(Apenas atualizei para o cfengine 3.3.1, ambiente misto isolado do CentOS / Fedora - o resto da rede corre alegremente no cf2).

    

Answer 1

David,

Os arquivos atualizados estão sendo copiados e o agente local cf-agent não reage às mudanças? Ou os arquivos atualizados não serão copiados até muito mais tarde?

A única razão pela qual posso pensar em cima da minha cabeça é que os relógios entre os sistemas estão fora de sincronia. Verifique / var / cfengine / inputs / cf_promises_validated - esse arquivo é preenchido com a última vez que as promessas foram verificadas no servidor e os clientes recarregam suas políticas locais usando esse registro de data e hora.

Você também pode postar sua pergunta no Fórum de Ajuda do CFEngine , onde ele pode ser visto por um número maior de especialistas da CFEngine:)

    

Answer 2

David,

Eu também suspeito que o clock seja distorcido, como o Diego. Pesquise cf_promises_validated em link , que pode fornecer alguns recursos. A chave são as promessas da cópia no seu failsafe.cf.

    

Answer 3

Você mencionou que acabou de atualizar seu CFEngine para 3.3.1.

Há um novo timestamp em / var / cfengine / masterfiles / cf_promises_validated em 3.3.1 (a versão anterior é um arquivo em branco que imaginei), o que significa que podemos apenas alterar uma maneira de copiar o arquivo de "mtime" para "digest "no seu atual failsafe.cf para evitar o problema do relógio do sistema. Veja também /var/cfengine/share/CoreBase/failsafe.cf, body copy_from u_rcp já possui um corpo composto "digest".

    

Answer 4

Como outros, eu suspeito que o clock seja distorcido. Verifique seus horários. Você também pode excluir o arquivo cf_promises_validated em / var / cfengine / inputs no agente remoto. Em seguida, ele verá que o arquivo cf_promises_validated em / var / cfengine / masterfiles no hub de políticas é diferente e prosseguirá com uma atualização completa da política.

A partir de 3.3.0, cf_promises_validated deve conter um carimbo de data e hora, para que não dependamos de sincronização de tempo adequada para atualizações de políticas.

Verifique seu failsafe.cf se você estiver usando a política de inicialização padrão.

A política de 3.3.1 ou 3.3.0 (não tenho certeza de qual gerou a prova de falha que estou observando) tem uma promessa com o identificador "check_valid_update" que usa u_rcp para atualizar o arquivo cf_promises_validated, se necessário. Se ele consertar a promessa, ele aumentará a classe / contexto validated_updates_ready, na qual a promessa com handle update_files_inputs_dir é restrita para atualizar o resto da política. Verifique no corpo copy_from u_rcp o que é usado para o atributo compare. Se o seu resumo, então, deve estar usando o conteúdo do arquivo em vez de apenas os timestamps nele.