etckeeper: контроль изменений конфигурации в /etc через git

Карточка изменения из общего процесса управления изменениями фиксирует, что должно было поменяться. А что поменялось в самом каталоге /etc на самом деле — обычно никто не фиксирует: конфигурации правят вручную, и через полгода никто не вспомнит, кто и зачем изменил параметр. etckeeper решает это просто: держит /etc под версионным контролем git и коммитит изменения автоматически. Ниже установка, типовой сценарий и результаты проверки.

Статья опирается на логику направления «Управление изменениями» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена в контейнере Debian 12 (etckeeper 1.18.20), после неё всё удалено.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Установка и автоматическая инициализация

apt install etckeeper git

Пакет сам создаёт репозиторий git в /etc и делает первый коммит со всем содержимым каталога — отдельно вызывать etckeeper init не нужно, это уже сделано post-install хуком пакета. В тесте сразу после установки git log в /etc показал «Initial commit» с сотнями файлов. Задайте, от чьего имени будут коммиты:

git config --file /etc/.git/config user.email "root@host"
git config --file /etc/.git/config user.name "root"

Как это работает

etckeeper подключается к менеджеру пакетов через хуки apt:

DPkg::Pre-Invoke  { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };
DPkg::Post-Invoke { "if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi"; };

Поэтому любая установка или обновление пакета, меняющие файлы в /etc, автоматически попадают в историю отдельным коммитом с сообщением вида «committing changes in /etc after apt run». Для изменений, которые вы вносите вручную, коммит нужно делать самостоятельно:

etckeeper commit "описание изменения"

Кроме того, установлен systemd-таймер etckeeper.timer (заход раз в сутки, первый запуск через 15 минут после загрузки) — он подхватывает изменения, сделанные в обход apt и без ручного коммита. Полагаться только на него не стоит: ежедневный коммит объединит несколько правок за день в одну запись и усложнит разбор истории.

Результат проверки: diff и откат

Изменили тестовый конфигурационный файл и закоммитили:

sed -i 's/port=8080/port=9090/' /etc/myapp/app.conf
sed -i 's/debug=false/debug=true/' /etc/myapp/app.conf
etckeeper commit "change app config to debug mode"

Просмотр разницы между версиями:

git -C /etc show HEAD -- myapp/app.conf

-port=8080
-debug=false
+port=9090
+debug=true

Откат именно этого изменения, без потери более поздних правок других файлов:

git -C /etc revert --no-edit HEAD

Команда создала новый коммит «Revert “change app config to debug mode”», и содержимое файла вернулось к исходному (port=8080, debug=false). История при этом не переписывается: видно и то, что изменили, и то, что откатили, и когда.

Важная ловушка: git revert не сработает на файле, который на самом деле является точкой монтирования, а не обычным файлом (так бывает, например, с /etc/hostname в контейнере) — команда вернёт «Device or resource busy». Для обычных конфигурационных файлов на сервере, не являющихся bind-монтированием, этой проблемы нет.

Что делать с историей

• Разбор инцидента или сбоя: git -C /etc log -p -- путь/к/файлу покажет все изменения файла по порядку с содержимым каждого.
• Сверка с карточкой изменения: сообщение коммита для ручных правок должно содержать номер заявки, чтобы историю можно было сопоставить с официальным процессом.
• Регулярный просмотр: раз в неделю бегло просмотреть коммиты за ручными изменениями (не от apt) — изменение без заявки в сообщении коммита повод для вопроса.
• Резервная копия самого репозитория: каталог /etc/.git нужно включить в общую стратегию копирования, иначе история изменений пропадёт вместе с сервером.

Порядок внедрения

1. Установите etckeeper на серверах, где конфигурацию правят вручную, а не только через конфигурационный менеджмент.
2. Задайте имя и почту для коммитов, по возможности разные для каждого администратора (не общий root), чтобы в истории было видно, кто правил.
3. Включите привычку коммитить вручную сразу после правки с осмысленным сообщением, а не полагаться на суточный таймер.
4. Добавьте каталог .git в резервное копирование вместе с остальным /etc.
5. Используйте историю при разборе инцидентов и сверяйте ручные изменения с карточками в системе управления изменениями.

Диагностика

Ограничения

etckeeper фиксирует только то, что лежит в /etc на диске, и не видит состояние, которое система хранит иначе (память работающих служб, записи в базах, таблицы файрвола, не сохранённые в файл). Он также не заменяет процесс управления изменениями с согласованием и окном работ: это журнал фактических изменений файлов, а не система согласования. Для контроля несанкционированных изменений за пределами коммитов используйте отдельный инструмент: AIDE.

Где это в модели зрелости

Материал относится к направлению «Управление изменениями» (материалы направления, карта зрелости). Уровень 2 требует, чтобы изменения были отслеживаемы и обратимы: журнал в git делает это для конфигурации на уровне файлов и дополняет карточку изменения технической деталью — что именно изменилось в байтах, а не только в описании.

Как проверить

1. В /etc есть репозиторий git с историей коммитов от установки пакетов.
2. Ручные изменения коммитятся с осмысленным сообщением сразу после правки.
3. Каталог .git внутри /etc входит в резервное копирование сервера.
4. Откат тестового изменения через git revert работает и не затрагивает более поздние правки других файлов.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация etckeeper: etckeeper.branchable.com.