Монітор серверів для змін, зроблених поза програмного забезпечення автоматизації

Компанія, в якій я працюю, зараз досліджує розгортання централізованої системи автоматизації (наприклад, Salt або Puppet) для наших серверів (Ubuntu/FreeBSD). Ми, ймовірно, підемо разом з Сольт, але я думаю, що це не має відношення до мого питання.

Моє запитання: чи є хороший спосіб для моніторингу машин для локальних змін, не включених до системи автоматизації?

Наприклад: для швидкого виправлення хтось запустив службу або змінив файл конфігурації на даній машині. Чи є спосіб перевірити такі речі, використовуючи Salt/Puppet/any? Або для цього потрібно використовувати зовнішні програми, такі як AIDE?

3
Чому солі, проти маріонетки, BCfg2, CFEngine і т.д.?
додано Автор Pedro, джерело
додано Автор Alvarolm, джерело
Файли стану конфігурації записуються в yaml/jinja2 і можуть бути розширені в python. Для мене це величезна річ, оскільки мені не доведеться вивчати рубінську або маріонеткову мову. Також Salt може керувати конфігурацією і виконувати віддалені команди. Так що немає необхідності в іншому інструменті у випадку, якщо мені потрібно запустити щось на декількох машинах (наприклад, перезапустити nfs клієнтів).
додано Автор Viller, джерело

6 Відповіді

Ви можете використовувати tripwire , щоб відстежувати зміни всіх відповідних файлів на сервері. Повертається, що після кожної автоматичної зміни конфігурації вам доведеться скинути відправлення.

1
додано
Деякі системи "tripwire" можуть дати вам приємні тригери для запуску перевірки перед кожним запуском автоматизації, а тихий - один після.
додано Автор Steve Scheffler, джерело

Не впевнені, що ви вже знайшли рішення, але ви можете скористатися Metafor Software , щоб відстежувати зміни всі відповідні файли та пакети.

Це було б набагато простіше, ніж AIDE, і дешевше, ніж Tripwire (Metafor у бета-версії).

Крім моніторингу змін, не включених до системи автоматизації, ви можете використовувати Metafor для перевірки справжнього стану ваших серверів після запуску Salt/Puppet.

1
додано

Як і пропозиція Tripwire, я впроваджую AIDE нові системи. Це доступне на обох платформах у вашому середовищі.

0
додано

Щось мені дуже подобається у солі - це державне тестування:

# salt \* state.highstate test=True

Дає вам гарний колоризований звіт, який повідомляє вам про те, що відповідає вашим визначеним станам, без фактичного застосування змін. Це дає вам те, що ви хочете в тому, що він показує вам, де стан ваших систем відхиляється від того, що система автоматизації хоче, щоб це було. Існують вагомі причини для цього, можливо, ви вивчаєте сіль або маєте делікатну систему, і не хочете виходити з системи автоматизації. Чим більше станів ви додаєте до солі, тим краще, але це означає, що ви можете рости органічно, як ви дізнаєтеся.

http://docs.saltstack.com/ref/states/testing.html

0
додано

Ви могли б написати сценарій з find (1) і md5 (1), який бере MD5sums всіх відповідних файлів і порівнює їх з MD5sums, що зберігаються поза.

0
додано

Aide буде використовувати aide.conf, щоб з'ясувати, які саме файли/каталоги слід контролювати і як. Можна було б написати шаблон Puppet, який міг би встановити aide.conf, щоб не дивитися на directores/файли, які створюються (і можуть бути перевірені) за допомогою rpm.

З іншого боку, ви можете просто перерахувати файл, який ви хочете контролювати ...

Для того, щоб повторно ініціалізувати Aide DB на оновлення пакетів, aide --init необхідно запускати кожного разу, коли yum виконується через Puppet (тоді новостворену БД необхідно перемістити на місце). Помічник так довго запускає цю ініціалізацію, що це неможливо (для нас). У вашому випадку це може бути добре.

Використовуйте приємно, щоб отримати помічник, щоб не бути ресурсом свиней. Хороший фактор -19 був запропонований www.howtoforge.com.

0
додано