Marioneta: ejecutar el comando de shell cuando se actualiza el archivo (o paquete)

Quiero ejecutar mysql_tzinfo_to_sqlcada vez que cambie el paquete tzinfo (en Ubuntu Server). Supuse que Puppet puede encargarse de esto.

Pensé que Puppet reaccionaría a un cambio en la versión del paquete, o si no, a un cambio en las marcas de tiempo de un archivo contenido en el paquete.

La única forma en que puedo ver para hacer esto es tener un recurso sin acción directa, y tener un ejecutivo dependiendo de ello.

Las preguntas que tengo son:

1. ¿Es posible definir un archivo que solo se usa para Notificar a otro recurso (como exec )?
2. ¿Es posible definir un recurso de paquete para que otro recurso (como exec ) se active cuando el paquete cambia o se actualiza?
3. ¿Es posible definir un recurso ejecutivo que ejecute una línea de comando de shell (con tuberías y redirección, por ejemplo) en lugar de un comando del sistema de archivos?

En conjunto, parece abrumador.

SEGUIMIENTO : ¡Fantásticas respuestas! En aras de la integridad (y para el registro), debo tener en cuenta lo siguiente:

1. El comando de shell completo de interés es mysql_tzinfo_to_sql | mysql -u root -p password (carga tzinfo en una base de datos MySQL para uso de MySQL).
2. La auditoría de /etc/tzinfosería inútil ya que esta es simplemente la configuración de zona horaria local; el objetivo es observar los cambios en los datos de tzinfo en sí (por lo tanto, la observación de /usr/share/zoneinfo).
3. Del mismo modo, los contenidos serían incorrectos de ver, ya que es probable que no cambien; lo mejor sería mirar el mtime o todo ya que los tiempos de archivo deberían cambiar después de cada actualización de tzinfo.

Además, James Turnbull escribió todo sobre la auditoría cuando se introdujo. La referencia de metaparámetro contiene una breve descripción del funcionamiento del auditparámetro.

Use el atributo de auditoría para rastrear el contenido del archivo o el número de versión del paquete y activar el cambio suscribiéndose al recurso del paquete. Algunos problemas con esto, esto no funciona con --noop porque el archivo state.yaml actualizará la versión del paquete / suma de comprobación md5 en modo --noop. No estoy seguro de si este es un error pendiente ya que no puedo rastrearlo en este momento.

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

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

Un método más confiable es simplemente duplicar el archivo en otro lugar y usarlo para activar actualizaciones (la ubicación no es importante, solo estamos rastreando el tzinfo original como fuente).

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

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

El segundo método, por supuesto, no funciona con paquetes, pero evitaría los problemas --noop y state.yaml.

Con respecto a la tercera pregunta, sí, puede usar tubería y redireccionamientos (use un título y coloque el comando en el atributo de comando):

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

Sí, deberías poder hacer esto.

* ejemplo 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. Sí, a través del metaparámetro de notificación. Sin embargo, no estoy 100% seguro de que la nueva función de auditoría en Puppet 2.6 active una notificación si la versión del paquete cambia fuera del control de Puppet.

2. Sí, con refreshonly => true

3. Sí, mira mi ejemplo. Puppet ejecuta comandos exec fuera de un shell interactivo para simplicidad y seguridad. Puede hacer que Puppet use bash en modo subshell con el modificador -c, pero tenga en cuenta las comillas.

Creo que he podido hacer que esto funcione. Aquí están los bits relevantes de mi manifiesto de títeres:

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',
}

después de la primera, se omite el ejecutable mysql_tzinfo. probado tocando / usr / share / zoneinfo / Etc / UTC, lo que llevó a mysql_tzinfo exec a ejecutarse en el siguiente.

Esta pregunta es antigua, pero la busqué en busca de otra cosa y quise agregar una respuesta alternativa para su consideración.

No utiliza títeres: ya que queremos activar una instalación / actualización de RPM, ¿por qué no utilizar un activador de RPM? Aprovecha el mismo sistema utilizado para realizar la instalación, extendiéndolo adecuadamente de la manera para la cual fue diseñado.

Construir el RPM del disparador es muy simple, y aunque no es divertido de aprender, una vez que se hace el primero, se puede repetir para otras aplicaciones y condiciones también muy fácilmente; por lo tanto, los costos no son cero, pero los beneficios superan rápidamente a esos costos.

Si bien estamos aquí para Puppet, y el problema se puede resolver con Puppet, me preocupa que aproveche una parte débil de una herramienta para responder mal a una condición que es mucho más fácil de activar con una herramienta que ya está en el host y una herramienta en el que la mayoría de los administradores en la caja deberían haber sumergido su dedo del pie. Perdón por sugerir una solución fuera de las líneas, pero si está navegando por este mensaje en el futuro como lo hice yo, y el disparador RPM es una opción para usted, considérelo.