Puppet: Executando o comando shell quando o arquivo (ou pacote) é atualizado

Quero executar mysql_tzinfo_to_sqlsempre que o pacote tzinfo (no Ubuntu Server) for alterado. Imaginei que Puppet pode cuidar disso.

Eu pensei que o Puppet reagiria a uma alteração na versão do pacote ou, se não, a uma alteração nos carimbos de data e hora de um arquivo contido no pacote.

A única maneira de ver isso é ter um recurso sem ação direta e ter um executivo dependendo dele.

As perguntas que tenho são:

1. É possível definir um arquivo que é usado apenas para notificar outro recurso (como exec )?
2. É possível definir um recurso de pacote para que outro recurso (como exec ) seja ativado quando o pacote for alterado ou atualizado?
3. É possível definir um recurso exec que executa uma linha de comando do shell (com pipes e redirecionamento por exemplo) em vez de um comando do sistema de arquivos?

Tomados em conjunto, parece esmagador.

SEGUIMENTO : Respostas fantásticas! No interesse da integridade (e para o registro), devo observar o seguinte:

1. O comando shell de interesse completo é mysql_tzinfo_to_sql | mysql -u root -p password (ele carrega tzinfo em um banco de dados MySQL para uso do MySQL).
2. A auditoria /etc/tzinfoseria inútil, pois é apenas a configuração do fuso horário local; o objetivo é observar as alterações nos dados do tzinfo (assim, a observação de /usr/share/zoneinfo).
3. Da mesma forma, o conteúdo seria a coisa errada a ser observada - pois é provável que não mudem; o melhor seria assistir o mtime ou tudo, já que os tempos de arquivo devem mudar após cada atualização do tzinfo.

Além disso, James Turnbull escreveu tudo sobre auditoria quando foi introduzido. A Referência de Metaparameter contém uma breve descrição do funcionamento do auditparâmetro.

Use o atributo de auditoria para rastrear o conteúdo do arquivo ou o número da versão do pacote e acionar a alteração assinando o recurso do pacote. Alguns problemas com isso, isso não funciona com --noop porque o arquivo state.yaml atualiza o arquivo md5 checksum / versão do pacote no modo --noop. Não tenho certeza se esse é um bug pendente, pois não consigo localizá-lo no momento.

file { '/etc/tzinfo':
  audit => content,
}

exec { '/usr/bin/mysql_tzinfo_to_sql':
  subscribe => File['/etc/tzinfo'],
}

Um método mais confiável é apenas duplicar o arquivo em outro local e usá-lo para acionar atualizações (a localização não é importante, estamos apenas rastreando o tzinfo original como fonte).

file { '/etc/puppet/stage/tzinfo':
  source => '/etc/tzinfo',
}

exec { '/usr/bin/mysql_tzinfo_to_sql':
  subscribe => File['/etc/tzinfo'],
}

O segundo método, obviamente, não funciona com pacotes, mas você evitaria os problemas --noop e state.yaml.

Com relação à terceira pergunta, sim, você pode usar pipe e redirecionamentos (use um título e coloque o comando no atributo de comando):

exec { 
  '/bin/echo foo | grep foo > /tmp/foo':
}

Sim, você deve conseguir fazer isso.

* exemplo de código teórico

package{'tzinfo':
  audit  => all,
  notify => Exec['mysql_tzinfo_to_sql'],
}

exec{'mysql_tzinfo_to_sql':
  refreshonly  => true,
  command      => "bash -c '/usr/local/bin/mysql_tzinfo_to_sql >> /var/log/stuff.log'",
}

1. Sim, através do meta-parâmetro de notificação. No entanto, não tenho 100% de certeza de que o novo recurso de auditoria no fantoche 2.6 acionará uma notificação se a versão do pacote mudar fora do controle do fantoche.

2. Sim, com refreshonly => true

3. Sim, veja meu exemplo. O Puppet executa comandos exec fora de um shell interativo para simplicidade e segurança. Você pode fazer o fantoche usar o bash no modo subshell com a opção -c, mas preste atenção nas aspas.

Acredito que consegui fazer isso funcionar. aqui estão os bits relevantes do meu manifesto de marionetes:

file { '/usr/share/zoneinfo':
  audit => mtime,
  recurse => true,
  notify => Exec['mysql_tzinfo']
}

exec { 'mysql_tzinfo':
  refreshonly => true,
  command => 'mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql',
}

após o primeiro, o exec mysql_tzinfo é ignorado. testado por touch'ing / usr / share / zoneinfo / Etc / UTC, que solicitou que o mysql_tzinfo executasse a execução no próximo.

Essa pergunta é antiga, mas eu a percorri procurando outra coisa e queria adicionar uma resposta alternativa para consideração.

Ele não usa fantoches: como queremos ativar uma instalação / atualização de RPM, por que não usar um gatilho de RPM? Ele aproveita o próprio sistema usado para fazer a instalação, estendendo-o adequadamente da maneira para a qual foi projetado.

Construir o RPM do gatilho é muito simples e, embora não seja divertido de aprender, uma vez feito o primeiro, ele pode ser repetido para outros aplicativos e condições com muita facilidade também - portanto, os custos são diferentes de zero, mas os benefícios superam rapidamente e rapidamente os demais. custos.

Enquanto estamos aqui para o Puppet, e o problema é solucionável com o fantoche, receio que ele esteja aproveitando uma parte fraca de uma ferramenta para responder mal a uma condição que é muito mais fácil de ativar com uma ferramenta que já está no host e em uma ferramenta no qual a maioria dos administradores na caixa deveria ter mergulhado o dedo do pé. Desculpe sugerir uma solução fora das linhas, mas se você estiver vagando por esta mensagem no futuro como eu fiz, e o gatilho RPM for uma opção para você, considere-a.