Puppet：ファイル（またはパッケージ）が更新されたときにシェルコマンドを実行する

（Ubuntuサーバー上の）tzinfoパッケージが変更さmysql_tzinfo_to_sqlれるたびに実行したいと思います。私は人形がこれを処理できると考えました。

Puppetはパッケージバージョンの変更に反応するか、そうでなければパッケージに含まれるファイルのタイムスタンプの変更に反応すると思いました。

これを実行するために私が見ることができる唯一の方法は、直接的なアクションのないリソースを持ち、それに依存するexecを持つことです。

私が持っている質問は：

1. 別のリソース（execなど）に通知するためだけに使用されるファイルを定義することはできますか？
2. パッケージが変更または更新されたときに別のリソース（execなど）がアクティブになるようにパッケージリソースを定義することは可能ですか？
3. ファイルシステムからのコマンドの代わりに、シェルコマンドライン（パイプとリダイレクトなど）を実行するexecリソースを定義することはできますか？

まとめると、圧倒的です。

フォローアップ：素晴らしい答え！完全性のために（そして記録のために）、次のことに注意してください。

1. 関心のある完全なシェルコマンドは mysql_tzinfo_to_sql | mysql -u root -p password （MySQLを使用するためにtzinfoをMySQLデータベースにロードする）です。
2. /etc/tzinfoこれは単なるローカルタイムゾーン構成であるため、の監査は無駄です。目的は、tzinfoデータ自体の変化を監視することです（したがって、の監視/usr/share/zoneinfo）。
3. 同様に、内容が変化することはほとんどないため、内容を見るのは間違っています。tzinfoを更新するたびにファイル時間が変更されるため、mtimeまたはallを監視するのが最善です。

また、James Turnbull は、監査が導入されたときに監査についてすべて書きました。メタパラメータリファレンスの働きの簡単な説明が含まれauditたパラメータを。

監査属性を使用して、ファイルのコンテンツまたはパッケージのバージョン番号を追跡し、パッケージリソースをサブスクライブして変更をトリガーします。これに関するいくつかの問題、これは--noopでは機能しません。state.yamlファイルが--noopモードでファイルmd5チェックサム/パッケージバージョンを更新するためです。現時点では追跡できないため、これが保留中のバグかどうかはわかりません。

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

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

より信頼できる方法は、ファイルを別の場所に複製し、それを使用して更新をトリガーすることです（場所は重要ではなく、元のtzinfoをソースとして追跡しているだけです）。

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

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

もちろん、2番目の方法はパッケージでは機能しませんが、-noopおよびstate.yamlの問題は回避できます。

3番目の質問については、はい、パイプとリダイレクトを使用できます（タイトルを使用して、コマンド属性にコマンドを入力します）。

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

はい、できるはずです。

*理論的なコード例

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. はい、通知メタパラメータを介して。ただし、puppet 2.6の新しい監査機能が、puppetの制御外でパッケージバージョンが変更された場合に通知をトリガーすることを100％肯定するわけではありません。

2. はい、refreshonly => true

3. はい、私の例をご覧ください。Puppetは、シンプルさとセキュリティのために、対話型シェルの外部でexecコマンドを実行します。-cスイッチを使用してパペットにサブシェルモードでbashを使用させることができますが、引用符に注意してください。

私はこれを機能させることができたと信じています。ここに私の人形マニフェストの関連するビットがあります：

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

最初の起動後、mysql_tzinfo execはスキップされます。/ usr / share / zoneinfo / Etc / UTCをタッチしてテストしました。これにより、mysql_tzinfo execが次に実行されるようになります。

この質問は古いですが、私は何か他のものを探してそれをさまよって、検討のために別の答えを追加したいと思いました。

それはパペットを使用しません：RPMインストール/更新でトリガーしたいので、なぜRPMトリガーを使用しないのですか？これは、インストールの実行に使用されるシステムそのものを活用して、設計された方法で適切に拡張します。

トリガーRPMの作成は非常にシンプルで、学ぶのは面白くありませんが、最初のRPMが完了すると、他のアプリや条件に対しても簡単に繰り返すことができます。したがって、コストはゼロではありませんが、利益はそれらをすぐに大きく上回りますコスト。

私たちはPuppetのためにここにいますが、問題はpuppetで解決できますが、それはツールの弱い部分を利用して、すでにホスト上にあるツールとツールでトリガーするのがはるかに簡単な条件に不適切に応答することを心配していますボックスのほとんどの管理者は、つま先をつけるべきでした。行外で解決策を提案して申し訳ありませんが、私がしたように、今後このメッセージをさまよい、RPMトリガーがオプションである場合は、それを考慮してください。