Etckeeper: Git-история для /etc и быстрый аудит изменений конфигурации

Каталог /etc — это «нервная система» Linux-сервера: конфиги сервисов, политики безопасности, сеть, systemd-юниты, sudoers. На практике инциденты часто выглядят одинаково: «вчера всё работало», «после обновления пакет перезаписал конфиг», «кто-то что-то поменял, но непонятно что». Etckeeper решает две задачи одновременно: делает историю изменений /etc и ускоряет аудит/откат.

Идея простая: etckeeper инициализирует VCS-репозиторий (обычно Git) прямо в /etc, а затем делает коммиты в «правильные» моменты: перед/после работы пакетного менеджера, по расписанию и вручную. В итоге вы получаете привычные для разработки инструменты: дифф, лог, откат — но для серверной конфигурации.

Что даёт etckeeper на живом сервере

Важно зафиксировать ожидания: etckeeper — не «бэкап всей системы» и не замена полноценным резервным копиям. Это контроль версий и быстрый аудит именно /etc.

• Аудит изменений: быстро видно, что и когда поменялось, с диффом по строкам.
• Точечный rollback: можно вернуть конкретный файл/каталог к прошлой версии.
• Прозрачность обновлений: изменения до/после apt/dnf фиксируются автоматически.
• Проще расследовать падения: вместо «угадайки» открываете коммит и видите правку.

Etckeeper особенно полезен там, где нет строгого IaC (Ansible/Salt), но изменения всё равно происходят: руками, апдейтами, скриптами или панелями управления.

Предупреждения: секреты и модель угроз

Главная ошибка при внедрении: «раз репозиторий локальный и доступен только root, значит можно коммитить всё». Это рискованно. Даже локальная Git-история может уехать в бэкапы/снапшоты, попасть в образ, а удалить секрет из истории «настоящим образом» уже сложно.

Практический подход:

• не коммитить секреты (ключи, токены, пароли);
• секреты хранить отдельно: в файлах с правами 600 вне индекса, в environment-файлах systemd, либо во внешнем vault-решении;
• если секрет уже попал в историю — считать скомпрометированным, сделать ротацию, и только затем думать об очистке истории.

Если вы строите процесс ближе к GitOps, полезно отдельно посмотреть практики управления секретами: как хранить секреты в репозитории безопаснее с SOPS/age и GitOps.

Установка etckeeper и выбор VCS (Git)

Etckeeper поддерживает несколько VCS, но на практике чаще всего выбирают Git: он быстрый, удобный, есть инструменты для диффов и аудита.

Debian/Ubuntu

sudo apt update
sudo apt install etckeeper git

RHEL/AlmaLinux/Rocky/Oracle Linux

sudo dnf install etckeeper git

Проверка, что репозиторий создан

После установки etckeeper обычно инициализирует репозиторий в /etc. Проверяем:

sudo ls -la /etc/.git
sudo git -C /etc status

Если репозиторий не создан, инициализируйте вручную:

sudo etckeeper init
sudo etckeeper commit "Initial commit of /etc"

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды Финляндия

Смотреть тарифы

Как etckeeper делает коммиты: интеграция с пакетным менеджером

«Магия» etckeeper — в хуках пакетного менеджера. Типовой сценарий:

1. Перед установкой/обновлением пакетов фиксируется текущее состояние /etc.
2. После установки/обновления фиксируются изменения.
3. По сообщению коммита обычно понятно, что это было действие apt/dnf/yum.

В результате вы можете ответить на вопрос «что поменялось в конфигах после обновления nginx/sshd/systemd» без ручного сравнения файлов.

Ручные коммиты, когда правите конфиги руками

Автокоммиты от пакетного менеджера не покрывают изменения, которые админ делает вручную. Привычка простая: коммит до и после правки.

sudo etckeeper commit "Before changing sshd_config"
sudo etckeeper commit "Tune sshd hardening parameters"

Для более «чистого» контроля сначала посмотрите, что меняется:

sudo git -C /etc diff
sudo git -C /etc status

Ключевая настройка: /etc/etckeeper/etckeeper.conf

Откройте конфиг etckeeper и проверьте основные параметры:

sudo editor /etc/etckeeper/etckeeper.conf

• VCS — обычно git.
• COMMIT_BEFORE_INSTALL и COMMIT_AFTER_INSTALL — фиксация до/после установки пакетов (часто уже включено).
• AVOID_DAILY_AUTOCOMMITS — если ежедневные коммиты не нужны, их можно отключить.
• PUSH_REMOTE — автопуш на удалённый репозиторий включайте только если вы уверены, что в истории не окажутся секреты.

Если вы планируете хранить подобные репозитории на отдельном сервере, логичная база — изолированный VDS с ограниченным доступом и понятными бэкапами. Но даже в этом случае игноры и дисциплина по секретам обязательны.

Ежедневные автокоммиты и systemd-таймеры

Во многих дистрибутивах etckeeper добавляет «ежедневный снимок» /etc (через cron или systemd-таймер). Это страховка на случай, если изменения происходят вне пакетного менеджера, а ручной коммит забыли.

Проверьте, что у вас используется:

sudo systemctl list-timers | grep -i etckeeper
sudo ls -la /etc/cron.daily | grep -i etckeeper

Если ежедневные коммиты создают шум, чаще всего достаточно сочетания: оставить daily-коммиты как «сетку безопасности», а для важных изменений делать ручные коммиты с понятными сообщениями.

Исключения и секреты: что не должно попадать в историю

В /etc встречаются файлы, которые лучше не хранить в Git-истории:

• секреты: приватные ключи, токены, пароли;
• шумные автогенерируемые файлы, которые часто меняются и забивают историю;
• чувствительные данные, которые могут быть лишними для аудита конфигов.

В зависимости от дистрибутива игноры могут жить в /etc/.gitignore или в шаблонах etckeeper. Начните с проверки «что сейчас считается игнорируемым»:

sudo git -C /etc status --ignored

Практика: минимальные игноры под секреты и шум

Адаптируйте под свою систему и расположение файлов. Пример для старта:

# private keys (examples)
/ssl/private/
/letsencrypt/archive/
/letsencrypt/live/

# application secrets (examples)
/*/secrets*
/*/*secret*

# machine-specific noisy files (examples)
/adjtime
/ld.so.cache

Если секрет уже попал в историю, добавление в игнор его не «вычистит». Корректная последовательность действий:

1. Ротация секрета (перевыпустить ключ/сменить пароль/токен).
2. Добавить путь в игнор и убрать файл из индекса (если он отслеживается).
3. Дальше — решать, нужна ли очистка истории в вашем процессе (часто — нет, если ротация сделана).

Компромисс: конфиг в Git, секреты — отдельным include

Во многих сервисах можно разнести «настройки» и «секреты»: основной конфиг хранить в etckeeper, а секретные значения подключать отдельным файлом, который игнорируется и имеет права 600. Для systemd это часто делается через environment-файлы, для некоторых сервисов — через механизм include.

Если конфиг можно разнести на «публичную» часть и секреты — делайте это. Etckeeper останется инструментом аудита и восстановления, а secrets management будет решаться отдельно и безопаснее.

Аудит: как быстро понять, что сломало сервис

Типовой сценарий: «после обновления или правки сервис не стартует». Начните с аудита изменений в /etc.

Последние изменения с перечислением файлов

sudo git -C /etc log -n 20 --name-status

Дифф последнего коммита

sudo git -C /etc show --stat
sudo git -C /etc show

История и патчи для конкретного файла

sudo git -C /etc log -p -- /etc/ssh/sshd_config

Поиск коммитов, связанных с установкой/обновлением

sudo git -C /etc log --grep=install -n 50 --oneline
sudo git -C /etc log --grep=upgrade -n 50 --oneline

Восстановление: откат файла, каталога или всего /etc

Git в /etc помогает откатить конфиг, но не откатывает состояние пакетов, данные приложений и содержимое /var. Восстановление делайте аккуратно и по возможности точечно.

Откат одного файла к версии из конкретного коммита

sudo git -C /etc log --oneline -- /etc/nginx/nginx.conf
sudo git -C /etc checkout <commit_id> -- /etc/nginx/nginx.conf

После восстановления проверьте синтаксис и примените изменения:

sudo nginx -t
sudo systemctl reload nginx

Откат каталога

sudo git -C /etc checkout <commit_id> -- /etc/systemd/system

Полный откат /etc — только если понимаете последствия

Полный откат может затронуть сеть, резолвер, SSH, unit-файлы и прочее. Если всё же нужно вернуть /etc целиком, начните с защитного коммита, чтобы можно было вернуться назад:

sudo etckeeper commit "Safety commit before full rollback"
sudo git -C /etc reset --hard <commit_id>

Качество истории: практики для команды

• Осмысленные сообщения: «Enable TCP BBR» лучше, чем «fix».
• Один коммит — одна задача: не смешивайте правки разных сервисов.
• Защитный коммит перед рискованной правкой: сеть, SSH, firewall.
• Валидация конфигов перед перезапуском сервиса (пример: nginx -t).

Типовые грабли и как их обходить

Шум от автогенерируемых файлов

Некоторые файлы в /etc меняются «сами» (кэши, состояния, специфичные для хоста значения) и забивают историю. Решение — добавлять такие файлы в игноры и не пытаться делать из etckeeper систему контроля целостности.

Права и владельцы как источник неожиданных изменений

Git отслеживает режимы файлов, но не все атрибуты. Если расследуете инцидент по правам/ownership, etckeeper может помочь косвенно, но для строгого контроля нужны отдельные политики и инструменты.

Секреты случайно попали в коммиты

Алгоритм действий должен быть стандартным: ротация секрета, исключение из индекса, и только затем — решение про очистку истории (если это вообще требуется).

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как etckeeper сочетается с IaC и бэкапами

Даже если у вас есть Ansible/Terraform и конфиги «приходят» из репозитория, etckeeper полезен: он фиксирует фактическое состояние сервера и помогает ловить дрейф (ручные правки мимо IaC) и изменения после обновлений пакетов.

А регулярные бэкапы (снапшоты, file-level backup) etckeeper не заменяет, но дополняет: часто быстрее откатить один конфиг, чем поднимать полный бэкап ради пары строк в sshd_config. На внешнем периметре это особенно полезно в связке с базовой гигиеной TLS: SSL-сертификаты и строгие заголовки/HSTS лучше внедрять контролируемо, с понятной историей правок. По теме миграции и HSTS пригодится: миграция домена, 301 и HSTS без сюрпризов.

Быстрый чек-лист внедрения

1. Установить etckeeper и Git, убедиться, что репозиторий в /etc создан.
2. Проверить автокоммиты до/после install/upgrade пакетного менеджера.
3. Настроить игноры для секретов и «шумных» файлов.
4. Договориться в команде о правилах ручных коммитов и сообщениях.
5. Потренироваться: найти дифф по файлу и откатить один конфиг на тестовом сервисе.

Etckeeper превращает /etc из «чёрного ящика» в понятную историю изменений. Это один из самых быстрых способов повысить управляемость сервера: меньше случайных правок, быстрее аудит, проще восстановление после ошибок.