Puppet: esecuzione del comando shell quando il file (o pacchetto) viene aggiornato

Voglio correre mysql_tzinfo_to_sqlogni volta che cambia il pacchetto tzinfo (su Ubuntu Server). Ho pensato che Puppet potesse occuparsene.

Ho pensato che Puppet avrebbe reagito a una modifica della versione del pacchetto o, in caso contrario, a una modifica dei timestamp di un file contenuto nel pacchetto.

L'unico modo in cui posso vedere per fare questo è avere una risorsa senza azione diretta e avere un dirigente a seconda di ciò.

Le domande che ho sono:

1. È possibile definire un file che viene utilizzato solo per notificare un'altra risorsa (come exec )?
2. È possibile definire una risorsa pacchetto in modo che un'altra risorsa (come exec ) venga attivata quando il pacchetto cambia o si aggiorna?
3. È possibile definire una risorsa exec che esegue una riga di comando della shell (con pipe e reindirizzamento per esempio) invece di un comando dal filesystem?

Presi tutti insieme, sembra travolgente.

FOLLOWUP : risposte fantastiche! Nell'interesse della completezza (e per la cronaca), dovrei notare quanto segue:

1. Il comando di shell completo di interesse è mysql_tzinfo_to_sql | mysql -u root -p password (carica tzinfo in un database MySQL per l'uso di MySQL).
2. Il controllo di /etc/tzinfosarebbe inutile poiché si tratta semplicemente della configurazione del fuso orario locale; l'obiettivo è quello di controllare i cambiamenti nei dati tzinfo stessi (quindi la sorveglianza di /usr/share/zoneinfo).
3. Allo stesso modo, i contenuti sarebbero la cosa sbagliata da guardare - poiché è probabile che non cambino; la cosa migliore sarebbe di guardare il mtime o tutti dal momento che i FileTimes dovrebbe cambiare dopo ogni aggiornamento tzinfo.

Inoltre, James Turnbull ha scritto tutto sull'auditing quando è stato introdotto. Il riferimento al metaparametro contiene una breve descrizione del funzionamento del auditparametro.

Utilizzare l'attributo audit per tenere traccia del contenuto del file o del numero di versione del pacchetto e attivare la modifica sottoscrivendo la risorsa del pacchetto. Alcuni problemi con questo, questo non funziona con --noop perché il file state.yaml aggiornerà il file md5 checksum / versione del pacchetto in modalità --noop. Non sono sicuro che si tratti di un bug in sospeso poiché al momento non riesco a rintracciarlo.

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

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

Un metodo più affidabile consiste solo nel duplicare il file altrove e utilizzarlo per attivare gli aggiornamenti (la posizione non è importante, stiamo solo monitorando l'originale tzinfo come sorgente).

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

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

Il secondo metodo ovviamente non funziona con i pacchetti, ma eviteresti i problemi --noop e state.yaml.

Per quanto riguarda la terza domanda, sì, puoi usare pipe e reindirizzamenti (usa un titolo e inserisci il comando nell'attributo command):

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

Sì, dovresti essere in grado di farlo.

* esempio di codice teorico

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ì, tramite il meta-parametro di notifica. Tuttavia, non sono sicuro al 100% che la nuova funzione di controllo in Puppet 2.6 attiverà una notifica se la versione del pacchetto cambia al di fuori del controllo di Puppet.

2. Sì, con refreshonly => true

3. Sì, vedi il mio esempio. Puppet esegue i comandi exec al di fuori di una shell interattiva per semplicità e sicurezza. Puoi fare in modo che Puppet usi bash in modalità subshell con l'opzione -c, ma fai attenzione alle virgolette.

credo di essere riuscito a farlo funzionare. ecco i pezzi rilevanti del mio manifest di marionette:

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

dopo il primo, il mysql_tzinfo exec viene saltato. testato toccando / usr / share / zoneinfo / Etc / UTC, che ha richiesto l'esecuzione di mysql_tzinfo exec per l'esecuzione al successivo.

Questa domanda è vecchia, ma l'ho vagata cercando qualcos'altro e volevo aggiungere una risposta alternativa per considerazione.

Non usa le marionette: poiché vogliamo innescare un'installazione / aggiornamento RPM perché non usare un trigger RPM? Sfrutta lo stesso sistema utilizzato per eseguire l'installazione, estendendolo correttamente nel modo in cui è stato progettato.

Costruire il trigger RPM è molto semplice e, sebbene non sia divertente da imparare, una volta fatto il primo può essere ripetuto anche per altre app e condizioni molto facilmente - quindi, i costi sono diversi da zero ma i vantaggi superano rapidamente e ampiamente quelli costi.

Mentre siamo qui per Puppet e il problema è risolvibile con Puppet, temo che stia sfruttando una parte debole di uno strumento per rispondere male a una condizione che è molto più facile da attivare con uno strumento che è già sull'host e uno strumento in cui la maggior parte degli amministratori sulla scatola avrebbe dovuto immergersi in punta di piedi. Mi dispiace suggerire una soluzione al di fuori delle linee, ma se stai vagando su questo messaggio in futuro come ho fatto io, e il trigger RPM è un'opzione per te, ti preghiamo di considerarlo.