Etckeeper на Linux VDS: версионируем /etc в Git и безопасно откатываем конфиги

На VDS большинство важных решений живёт в /etc: конфиги SSH, systemd, Nginx или Apache, PHP-FPM, cron, сетевые настройки, правила файрвола, параметры пакетного менеджера. Проблема в том, что эти файлы часто меняются вручную, скриптами, панелями управления и обновлениями пакетов. Через неделю уже сложно вспомнить, почему появился новый параметр, кто поправил порт SSH и после какого апдейта сервис начал падать.

etckeeper решает эту задачу простым и админским способом: он делает из /etc репозиторий Git, автоматически фиксирует изменения до и после операций пакетного менеджера и помогает быстро посмотреть diff или вернуть рабочую версию файла. Это не замена бэкапам и не полноценная CMDB, но отличный «чёрный ящик» для конфигурации Linux-сервера.

Главная ценность etckeeper не в том, что он «сохраняет файлы», а в том, что он показывает контекст: что изменилось, когда изменилось и с чем это можно связать.

Когда etckeeper особенно полезен

На небольшом сервере кажется, что всё и так под контролем: один администратор, несколько сайтов, пара сервисов. Но именно на таких VDS часто делают быстрые правки «на минуту»: поменяли лимит в PHP, добавили location в Nginx, временно отключили проверку, обновили пакет, забыли зафиксировать состояние. Через месяц временное становится постоянным, а причина инцидента теряется в истории shell.

Первая типовая ситуация — обновления системы. Перед установкой или удалением пакетов etckeeper делает коммит текущего состояния, а после операции фиксирует результат. Если новая версия пакета перезаписала конфиг или добавила файл в /etc/systemd/system, это будет видно.

Вторая ситуация — ручные изменения. Перед рискованной правкой можно сделать коммит с понятным сообщением, затем изменить конфиг, проверить сервис и при необходимости откатить один файл. Это быстрее и чище, чем плодить копии вида nginx.conf.bak, nginx.conf.old, nginx.conf.final2.

Третья — разбор инцидентов. Если сайт перестал отвечать после «невинной» правки, можно открыть историю /etc и найти, что именно менялось за последние часы. Особенно удобно, когда доступ к серверу есть у нескольких людей или часть изменений делает автоматизация.

Что важно понимать до установки

/etc — не обычный каталог с публичным кодом. Там могут быть секреты: хэши паролей, приватные ключи, токены API, пароли баз данных, ключи DKIM, параметры подключения к внешним сервисам. Git хранит не только текущую версию файла, но и историю. Если секрет однажды попал в коммит, простое удаление файла из рабочей копии не уберёт его из истории репозитория.

Поэтому базовое правило такое: локальный репозиторий etckeeper должен быть доступен только root, а удалённый репозиторий, если он нужен, должен быть приватным, контролируемым и защищённым. Не стоит отправлять сырой /etc в случайный общий Git-сервис или репозиторий, доступ к которому имеют разработчики без админских полномочий.

Также etckeeper не заменяет резервное копирование. Он помогает откатить конфигурационный файл, но не восстановит базу данных, содержимое /var/www, почтовые ящики или состояние диска после серьёзной аварии. Хорошая схема выглядит так: регулярные бэкапы всего важного плюс etckeeper для понятной истории системных настроек.

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

Установка etckeeper на популярные Linux-дистрибутивы

Etckeeper есть в репозиториях большинства серверных дистрибутивов. Для работы нам нужен сам etckeeper и Git. Команды ниже рассчитаны на выполнение от пользователя с sudo.

Debian и Ubuntu

sudo apt update
sudo apt install etckeeper git

В Debian/Ubuntu пакет обычно сразу интегрируется с apt. Это значит, что при установке, удалении и обновлении пакетов etckeeper сможет делать автоматические коммиты вокруг операций пакетного менеджера.

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux

В RHEL-based системах etckeeper чаще всего доступен через EPEL. Если EPEL ещё не подключён, установите его, затем поставьте etckeeper и Git.

sudo dnf install epel-release
sudo dnf install etckeeper git

На некоторых минимальных образах пакет epel-release может отсутствовать в базовых репозиториях провайдера. В таком случае сначала проверьте подключённые репозитории и политику вашей ОС. Для production-сервера лучше не добавлять сторонние репозитории «наугад»: фиксируйте, что именно включили, и контролируйте приоритеты.

Fedora

sudo dnf install etckeeper git

Fedora часто получает более свежие версии пакетов, но принцип работы тот же: Git-репозиторий в /etc, хуки для пакетного менеджера и ежедневные автокоммиты при включённой настройке.

Первичная настройка: Git, права и первый коммит

После установки стоит проверить конфигурацию etckeeper. Основной файл — /etc/etckeeper/etckeeper.conf. Нас интересует система контроля версий и режим автокоммитов.

sudo grep -E '^(VCS|AVOID_DAILY_AUTOCOMMITS|HIGHLEVEL_PACKAGE_MANAGER|LOWLEVEL_PACKAGE_MANAGER)=' /etc/etckeeper/etckeeper.conf

Для Git обычно нужна строка VCS='git'. В большинстве установок она уже выставлена. Если у вас в файле выбран другой VCS, отредактируйте конфиг и оставьте Git.

sudo editor /etc/etckeeper/etckeeper.conf

Типичный минимальный набор выглядит так:

VCS='git'
AVOID_DAILY_AUTOCOMMITS=0
AVOID_COMMIT_BEFORE_INSTALL=0

Параметр AVOID_DAILY_AUTOCOMMITS=0 разрешает ежедневные автокоммиты, если в /etc накопились незафиксированные изменения. Параметр AVOID_COMMIT_BEFORE_INSTALL=0 разрешает коммит перед установкой пакетов. Это удобно: если обновление сломало конфиг, у вас есть точка «до».

Теперь инициализируем репозиторий. Если пакет уже сделал это автоматически, команда сообщит, что репозиторий существует; это не страшно.

sudo etckeeper init

Перед первым коммитом полезно указать локальные данные автора для Git. Это не обязательно, но потом история будет читаться приятнее.

sudo git -C /etc config user.name 'root on vds'
sudo git -C /etc config user.email 'root@localhost'

Сделайте первый коммит. Он зафиксирует текущее состояние /etc и станет базовой точкой для дальнейших сравнений.

sudo etckeeper commit 'Initial /etc state on VDS'

Проверьте статус:

sudo etckeeper vcs status

Если всё чисто, Git покажет, что изменений нет. Если есть неотслеживаемые файлы, не спешите коммитить всё подряд: сначала проверьте, нет ли там временных файлов, приватных ключей, дампов или мусора от редакторов.

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

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

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

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

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

Что исключить из Git в /etc

Etckeeper по умолчанию уже умеет игнорировать часть временных файлов, но на реальном сервере почти всегда стоит настроить /etc/.gitignore под свою инфраструктуру. Нельзя дать универсальный список для всех VDS: у кого-то в /etc лежит ключ приложения, у кого-то — только системные настройки. Но есть категории, которые стоит проверить отдельно.

• Временные файлы редакторов: *.swp, *~, *.tmp.
• Локальные одноразовые бэкапы: *.bak, *.orig, если они содержат секреты или засоряют историю.
• Сгенерированные файлы, которые пересоздаются автоматически и не несут полезной истории.
• Файлы с приватными ключами и токенами, если вы планируете отправлять репозиторий на удалённое хранение.

Откройте файл игнорирования:

sudo editor /etc/.gitignore

Пример аккуратного стартового варианта:

*~
*.swp
*.tmp
*.bak
*.orig
.DS_Store

С секретами сложнее. Например, исключить все приватные ключи SSH из истории может показаться хорошей идеей, но тогда вы потеряете контроль над изменениями ключей хоста. С другой стороны, если репозиторий будет уходить за пределы сервера, хранение таких данных в Git может быть нежелательным. Здесь нет магической настройки: надо осознанно решить, что именно вы версионируете, кто имеет доступ к репозиторию и как защищён удалённый бэкап.

Если сомневаетесь, сначала используйте etckeeper только локально. Удалённый репозиторий подключайте после ревизии содержимого и правил доступа.

Повседневная работа: status, diff, log

Etckeeper не заставляет помнить отдельный набор команд: внутри он использует Git. Удобная форма — запускать Git через etckeeper vcs, находясь в любом каталоге.

Посмотреть незакоммиченные изменения:

sudo etckeeper vcs status

Посмотреть diff по всем изменённым файлам:

sudo etckeeper vcs diff

Посмотреть diff конкретного файла, например SSH:

sudo git -C /etc diff -- ssh/sshd_config

Посмотреть историю:

sudo git -C /etc log --oneline --decorate -n 20

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

sudo git -C /etc show --stat HEAD

Перед ручной правкой полезно делать осмысленный коммит. Например, вы собираетесь поменять лимиты PHP-FPM или добавить новый виртуальный хост веб-сервера:

sudo etckeeper commit 'Before changing php-fpm pool limits'

После правки проверьте конфигурацию сервиса штатной командой. Для Nginx это может быть nginx -t, для Apache — apachectl configtest, для SSH — sshd -t, для systemd unit — systemd-analyze verify. Если проверка прошла успешно и сервис работает, зафиксируйте результат:

sudo etckeeper commit 'Tune php-fpm pool limits for site load'

Так история превращается не в поток безымянных автокоммитов, а в понятный журнал решений. Через полгода сообщение Tune php-fpm pool limits for site load будет намного полезнее, чем «changed files».

Автокоммиты при apt и dnf: как проверить

Одна из сильных сторон etckeeper — интеграция с пакетным менеджером. После установки небольшого пакета можно посмотреть, появились ли коммиты «до» и «после». Для безопасной проверки выберите пакет, который действительно нужен на сервере, или дождитесь ближайшего планового обновления.

На Debian/Ubuntu:

sudo apt install needrestart
sudo git -C /etc log --oneline -n 10

На RHEL-based и Fedora:

sudo dnf install bash-completion
sudo git -C /etc log --oneline -n 10

Если автокоммитов нет, проверьте настройки AVOID_COMMIT_BEFORE_INSTALL, HIGHLEVEL_PACKAGE_MANAGER и наличие файлов интеграции в каталоге пакетного менеджера. Также убедитесь, что репозиторий в /etc инициализирован и первый коммит уже сделан.

Ежедневные автокоммиты обычно выполняются через cron или systemd timer — зависит от дистрибутива и версии пакета. Проверить systemd-таймеры можно так:

systemctl list-timers | grep etckeeper

Если таймера нет, это не всегда ошибка: в вашей сборке может использоваться cron. Посмотрите системные задания:

ls -l /etc/cron.daily | grep etckeeper

Как откатить один файл после неудачной правки

Самый частый сценарий: поправили конфиг, сервис не стартует, нужно быстро вернуть прежнюю версию одного файла. Сначала посмотрите, что изменилось:

sudo git -C /etc diff -- nginx/nginx.conf

Если нужно вернуть файл к состоянию последнего коммита:

sudo git -C /etc checkout -- nginx/nginx.conf

Затем проверьте конфигурацию сервиса и перезагрузите его штатным способом:

sudo nginx -t
sudo systemctl reload nginx

Если нужно вернуть файл не к последнему коммиту, а к конкретной старой версии, найдите нужный коммит:

sudo git -C /etc log --oneline -- nginx/nginx.conf

Затем восстановите файл из выбранного коммита. Вместо abc1234 подставьте нужный хеш:

sudo git -C /etc checkout abc1234 -- nginx/nginx.conf

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

sudo etckeeper commit 'Rollback nginx.conf to previous working version'

Как откатить изменения после обновления пакетов

После обновления пакетов ситуация тоньше. Не всегда правильно просто вернуть весь /etc назад: новая версия сервиса могла ожидать новый формат конфига, а пакет мог добавить unit, sysusers-файл или drop-in. Поэтому начинайте с анализа diff.

sudo git -C /etc log --oneline -n 20

Найдите коммит, который был сделан до установки или обновления. Затем сравните его с текущим состоянием:

sudo git -C /etc diff abc1234..HEAD

Если изменился один понятный файл, откатывайте только его. Если пакет принёс новый конфиг с расширением вроде .dpkg-dist, .rpmnew или .rpmsave, внимательно сравните варианты. Такие файлы часто являются подсказкой: пакетный менеджер не решился автоматически заменить ваш локальный конфиг и оставил новую версию рядом.

Для Debian/Ubuntu полезно искать dpkg-файлы:

sudo find /etc -name '*.dpkg-*' -print

Для RHEL-based систем и Fedora:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

После ручного слияния конфигов обязательно сделайте коммит с понятным сообщением. Например:

sudo etckeeper commit 'Merge package config changes after web stack update'

Удалённый репозиторий: когда нужен и как не навредить

Локальный Git в /etc помогает, пока сервер жив и диск доступен. Если VDS потерян целиком, локальная история тоже потеряна. Поэтому иногда etckeeper отправляют в удалённый приватный репозиторий: на отдельный backup-сервер, в закрытый Git-сервер организации или в репозиторий, доступный только администраторам.

Перед этим сделайте ревизию. Проверьте, какие файлы попадают в историю, кто сможет читать репозиторий, как защищены ключи доступа и есть ли процедура удаления секрета из истории, если он случайно закоммичен. Не подключайте remote автоматически «потому что так удобнее», пока не уверены в модели доступа.

Пример добавления удалённого репозитория по SSH:

sudo git -C /etc remote add origin git@backup.example:infra/vds-etc.git
sudo git -C /etc push -u origin master

В некоторых системах основная ветка называется main, в других — master. Проверьте имя текущей ветки:

sudo git -C /etc branch --show-current

Автоматический push после каждого коммита можно настроить отдельным скриптом или systemd timer, но я бы не начинал с этого. Для большинства одиночных VDS достаточно ручного push после важных изменений или отдельного регламентного задания, которое сначала проверяет отсутствие незакоммиченных секретов и только потом отправляет историю.

Безопасность репозитория /etc

Проверьте права на каталог /etc/.git. Обычно он принадлежит root и недоступен обычным пользователям. Это важно, потому что Git-объекты могут содержать данные из файлов, которые в рабочем дереве закрыты правами.

sudo ls -ld /etc/.git
sudo find /etc/.git -maxdepth 1 -type d -ls

Если вы обнаружили слишком широкие права, исправьте их:

sudo chown -R root:root /etc/.git
sudo chmod -R go-rwx /etc/.git

Не запускайте команды Git в /etc от обычного пользователя через странные обходные схемы. Если нужно дать человеку возможность смотреть историю, лучше организовать отдельный read-only экспорт без секретов или предоставить доступ через регламентированную админскую роль. Раздавать чтение всего /etc/.git всем участникам проекта — плохая идея.

Отдельно стоит помнить про секреты в истории. Если пароль базы данных попал в коммит, правильная реакция — не только удалить строку и сделать новый коммит. Пароль нужно ротировать: заменить в сервисе, обновить конфиги, перезапустить зависимые приложения и только затем решать, нужно ли чистить историю Git специальными инструментами. История, которая уже ушла на удалённый сервер, считается скомпрометированной для этого секрета.

Восстановление /etc на новом сервере или после аварии

Etckeeper может помочь при восстановлении VDS, но действовать нужно аккуратно. Не стоит бездумно накатывать старый /etc поверх другой версии ОС: различия в пакетах, сетевых интерфейсах, UUID, именах дисков и версиях systemd могут привести к нерабочему серверу.

Безопасный подход такой: сначала поднимите чистую систему той же версии или максимально близкой версии, установите нужные пакеты, затем используйте репозиторий etckeeper как источник конфигурационных файлов и истории. Восстанавливайте не весь каталог сразу, а группы настроек: SSH, веб-сервер, PHP, firewall, cron, systemd units.

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

Если вы клонируете репозиторий в /etc на тестовой машине или в rescue-среде, помните, что etckeeper хранит часть метаданных в файле /etc/.etckeeper. После checkout иногда нужно восстановить права и владельцев, но запускать этот файл стоит только из доверенного репозитория и после просмотра содержимого.

sudo less /etc/.etckeeper
sudo sh /etc/.etckeeper

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

Типовые ошибки и как их избежать

Первая ошибка — установить etckeeper и забыть про него. Без просмотра истории и осмысленных коммитов инструмент превращается в склад автоснимков. Возьмите привычку делать коммит перед существенной правкой и писать сообщение человеческим языком.

Вторая ошибка — коммитить мусор. Временные файлы редакторов, локальные копии, случайные дампы и старые архивы быстро засоряют историю. Настройте /etc/.gitignore и периодически смотрите status.

Третья ошибка — считать Git в /etc бэкапом всего сервера. Etckeeper хорош для конфигов, но у него другая задача. Для сайтов, баз данных, пользовательских файлов и контейнерных volume нужны отдельные резервные копии с проверкой восстановления.

Четвёртая ошибка — отправлять репозиторий на remote без ревизии секретов. Если вам нужен offsite-бэкап истории /etc, настройте приватный доступ, ограничьте круг администраторов и заранее решите, какие файлы исключаются.

Пятая ошибка — массово откатывать весь /etc после обновления. Это может вернуть старые конфиги, несовместимые с новыми пакетами. Чаще правильнее откатить один файл или вручную смержить изменения.

Мини-чеклист для VDS

• Установить etckeeper и git из репозиториев ОС.
• Проверить VCS='git' и разрешить автокоммиты, если они подходят вашему процессу.
• Сделать первый коммит чистого состояния /etc.
• Настроить /etc/.gitignore под временные файлы и локальный мусор.
• Проверить права на /etc/.git.
• Перед важными изменениями делать ручной коммит с понятным сообщением.
• После обновлений просматривать diff, особенно для .rpmnew, .rpmsave и .dpkg-*.
• Не считать etckeeper заменой полноценным бэкапам.
• Не отправлять репозиторий на удалённое хранение без ревизии секретов.

Итог

etckeeper — один из тех инструментов, которые не шумят и не требуют сложной инфраструктуры, но сильно упрощают жизнь администратору. На Linux VDS он даёт понятный version control для /etc: можно увидеть изменения после обновлений, сравнить конфиги, быстро откатить неудачную правку и восстановить логику настроек через месяцы после внедрения.

Начните с локального режима: установите пакет, сделайте первый коммит, настройте игнорирование мусора и попробуйте пару раз осознанно зафиксировать изменения перед правкой сервиса. Когда привычка появится, история /etc станет таким же естественным инструментом, как journalctl, systemctl status и проверка конфигурации перед reload.