Puppet: Запуск команды оболочки при обновлении файла (или пакета)

Я хочу запускать mysql_tzinfo_to_sqlкаждый раз, когда изменяется пакет tzinfo (на сервере Ubuntu). Я полагал, что Кукольный может позаботиться об этом.

Я думал, что Puppet будет реагировать на изменение версии пакета, а если нет, то на изменение временных меток файла, содержащегося в пакете.

Единственный способ, которым я могу это сделать, - это иметь ресурс без прямого действия и иметь исполнителя в зависимости от него.

У меня есть следующие вопросы:

1. Можно ли определить файл, который используется только для уведомления другого ресурса (например, exec )?
2. Можно ли определить ресурс пакета, чтобы при изменении или обновлении пакета активировался другой ресурс (например, exec )?
3. Можно ли определить ресурс exec, который запускает командную строку оболочки (например, с каналами и перенаправлением) вместо команды из файловой системы?

Взятые вместе, это кажется ошеломляющим.

FOLLOWUP : Фантастические ответы! В интересах полноты (и для записи) я должен отметить следующее:

1. Интересует полная команда оболочки mysql_tzinfo_to_sql | mysql -u root -p password (она загружает tzinfo в базу данных MySQL для использования MySQL).
2. Аудит /etc/tzinfoбесполезен, поскольку это просто конфигурация местного часового пояса; цель состоит в том, чтобы следить за изменениями в самих данных tzinfo (таким образом, отслеживая /usr/share/zoneinfo).
3. Аналогично, содержимое было бы неправильным, чтобы смотреть - поскольку они, вероятно, не изменятся; Лучше всего будет посмотреть mtime или все, так как времена файлов должны меняться после каждого обновления tzinfo.

Кроме того, Джеймс Тернбулл написал все об аудите, когда он был представлен. Metaparameter ссылка содержит краткое описание выработок с auditпараметром.

Используйте атрибут аудита, чтобы отслеживать содержимое файла или номер версии пакета и инициировать изменение, подписавшись на ресурс пакета. Несколько проблем с этим, это не работает с --noop, потому что файл state.yaml обновит контрольную сумму md5 / версию пакета в режиме --noop. Я не уверен, что это ожидающая ошибка, так как я не могу отследить ее в данный момент.

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

Второй метод, конечно, не работает с пакетами, но вы избежите проблем --noop и state.yaml.

Что касается третьего вопроса, да, вы можете использовать pipe и перенаправления (используйте заголовок и поместите команду в атрибуте команды):

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. Да, через мета-параметр notify. Однако я не уверен на 100%, что новая функция аудита в Puppet 2.6 вызовет уведомление, если версия пакета изменится вне контроля со стороны Puppet.

2. Да, с refreshonly => true

3. Да, смотрите мой пример. Puppet запускает команды exec вне интерактивной оболочки для простоты и безопасности. Вы можете использовать кукольный bash в режиме subshell с ключом -c, но обратите внимание на кавычки.

Я верю, что смог заставить это работать. вот соответствующие фрагменты моего манифестного манифеста:

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 запускаться дальше.

Этот вопрос старый, но я бродил по нему в поисках чего-то другого и хотел добавить альтернативный ответ для рассмотрения.

Он не использует puppet: так как мы хотим запустить установку / обновление RPM, почему бы не использовать триггер RPM? Он использует саму систему, используемую для установки, и расширяет ее должным образом так, как он был спроектирован.

Построение RPM триггера очень простое, и, хотя освоить его неинтересно, его можно легко повторить и для других приложений и условий - таким образом, затраты не равны нулю, но выгоды быстро и значительно перевешивают расходы.

Пока мы здесь для Puppet, и проблема решаема с Puppet, я беспокоюсь, что он использует слабую часть инструмента для плохой реакции на условие, которое гораздо легче вызвать с помощью инструмента, который уже находится на хосте, и инструмента в которую большинство администраторов на коробке должны были опустить свой палец ноги. Извините, что предложил решение за рамками, но если в будущем вы будете бродить по этому сообщению, как я, и триггер RPM является вариантом для вас, пожалуйста, рассмотрите его.