Con rối: Chạy lệnh shell khi tệp (hoặc gói) được cập nhật

Tôi muốn chạy mysql_tzinfo_to_sqlbất cứ khi nào gói tzinfo (trên Ubuntu Server) thay đổi. Tôi cho rằng Puppet có thể đảm nhận việc này.

Tôi nghĩ rằng một trong hai Puppet sẽ phản ứng với sự thay đổi trong phiên bản gói hoặc nếu không thì sẽ thay đổi dấu thời gian của một tệp có trong gói.

Cách duy nhất tôi có thể thấy để làm điều này là có một tài nguyên không có hành động trực tiếp và có một người thực thi tùy thuộc vào nó.

Những câu hỏi tôi có là:

1. Có thể xác định một tệp chỉ được sử dụng để Thông báo cho tài nguyên khác (chẳng hạn như exec ) không?
2. Có thể xác định tài nguyên gói để tài nguyên khác (như exec ) được kích hoạt khi gói thay đổi hoặc cập nhật không?
3. Có thể định nghĩa một tài nguyên exec chạy một dòng lệnh shell (ví dụ với các đường ống và chuyển hướng) thay vì một lệnh từ hệ thống tập tin?

Lấy tất cả cùng nhau, nó có vẻ áp đảo.

FOLLOWUP : Câu trả lời tuyệt vời! Vì lợi ích của tính đầy đủ (và đối với hồ sơ), tôi cần lưu ý những điều sau:

1. Lệnh shell quan tâm hoàn chỉnh là mysql_tzinfo_to_sql | mysql -u root -p password (nó tải tzinfo vào cơ sở dữ liệu MySQL để sử dụng MySQL).
2. Kiểm toán /etc/tzinfosẽ là vô ích vì đây chỉ là cấu hình múi giờ địa phương; mục tiêu là để theo dõi những thay đổi trong chính dữ liệu tzinfo (do đó là xem /usr/share/zoneinfo).
3. Tương tự như vậy, nội dung sẽ là điều sai lầm để xem - vì chúng có thể không thay đổi; tốt nhất là xem mtime hoặc tất cả vì thời gian quay phim sẽ thay đổi sau mỗi lần cập nhật tzinfo.

Ngoài ra, James Turnbull đã viết tất cả về kiểm toán khi nó được giới thiệu. Các Metaparameter Reference chứa một mô tả ngắn về các hoạt động của audittham số.

Sử dụng thuộc tính kiểm toán để theo dõi nội dung tệp hoặc số phiên bản gói và kích hoạt thay đổi bằng cách đăng ký tài nguyên gói. Một vài vấn đề với điều này, điều này không hoạt động với --noop vì tệp state.yaml sẽ cập nhật tệp md5 checksum / phiên bản gói trong chế độ --noop. Tôi không chắc đây có phải là một lỗi đang chờ xử lý hay không vì tôi không thể theo dõi nó vào lúc này.

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

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

Một phương pháp đáng tin cậy hơn là chỉ sao chép tệp ở nơi khác và sử dụng nó để kích hoạt cập nhật (vị trí không quan trọng, chúng tôi chỉ theo dõi tzinfo gốc dưới dạng nguồn).

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

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

Phương pháp thứ hai tất nhiên không hoạt động với các gói, nhưng bạn sẽ tránh được các vấn đề --noop và state.yaml.

Về câu hỏi thứ ba, có, bạn có thể sử dụng ống dẫn và chuyển hướng (sử dụng một tiêu đề và đặt lệnh trong thuộc tính lệnh):

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

Vâng, bạn sẽ có thể làm điều này.

* ví dụ mã lý thuyết

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. Có, thông qua các thông số meta thông báo. Tuy nhiên, tôi không khẳng định 100% rằng tính năng kiểm toán mới trong con rối 2.6 sẽ kích hoạt thông báo nếu phiên bản gói thay đổi ngoài tầm kiểm soát của con rối.

2. Có, với refreshonly => đúng

3. Vâng, xem ví dụ của tôi. Con rối chạy các lệnh exec bên ngoài lớp vỏ tương tác để đơn giản và bảo mật. Bạn có thể có con rối sử dụng bash trong chế độ subshell với công tắc -c, nhưng hãy chú ý đến dấu ngoặc kép.

Tôi tin rằng tôi đã có thể làm việc này. đây là các bit có liên quan trong bảng kê khai con rối của tôi:

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

sau lần đầu tiên, bộ thực thi mysql_tzinfo bị bỏ qua. đã được kiểm tra bằng touch'ing / usr / share / zoneinfo / Etc / UTC, điều này đã nhắc nhở mysql_tzinfo thực thi để chạy tiếp theo.

Câu hỏi này đã cũ, nhưng tôi lang thang qua nó để tìm kiếm một cái gì đó khác, và muốn thêm một câu trả lời thay thế để xem xét.

Nó không sử dụng con rối: Vì chúng tôi muốn kích hoạt cài đặt / cập nhật RPM, tại sao không sử dụng kích hoạt RPM? Nó tận dụng chính hệ thống được sử dụng để thực hiện cài đặt, mở rộng nó đúng cách theo cách mà nó được thiết kế.

Xây dựng RPM kích hoạt rất đơn giản và mặc dù không có gì thú vị để học, nhưng khi lần đầu tiên được thực hiện, nó có thể được lặp lại cho các ứng dụng và điều kiện khác rất dễ dàng - do đó, chi phí không bằng 0 nhưng lợi ích nhanh chóng và vượt xa những lợi ích đó chi phí.

Mặc dù chúng tôi ở đây vì Con rối và vấn đề có thể giải quyết được với con rối, tôi lo lắng rằng nó tận dụng một phần yếu của công cụ để phản ứng kém với điều kiện dễ kích hoạt hơn với một công cụ đã có trên máy chủ và công cụ trong đó hầu hết các quản trị viên trên hộp nên đã nhúng ngón chân của họ. Xin lỗi để đề xuất một giải pháp bên ngoài các dòng, nhưng nếu bạn đi lang thang qua tin nhắn này trong tương lai như tôi đã làm và trình kích hoạt RPM là một tùy chọn cho bạn, vui lòng xem xét nó.