Наверное каждый слышал о рекомендации выполнять резервное копирование конфигурационных файлов перед их редактированием. Так же бывают случаи когда обновление пакета или системы в целом приводит к перезаписи файлов с настройками в результате чего что то перестает работать. Если вам известны подобные проблемы то продукт etckeeper то что нужно.
Как это работает
В основе всего лежит система контроля версий — Concurrent Versions System (CVS). Так как /etc традиционно используется для хранения конфигурационных файлов, преимущественно текстовых, CVS здесь подходит как нельзя лучше. Но даже учитывая простоту использования современных систем версионного контроля они имеют тот же недостаток, что и резервное копирование конфигов в ручную. Администраторы попросту забывают или ленятся ими пользоваться будучи уверенными, что все пройдет гладко. По этому, я рекомендую поставить себе на вооружение маленькую но полезнейшую утилиту etckeeper которая будет это делать за вас.
Суть утилиты заключается в том, что бы автоматически делать резервное копирование состояния /etc до и после установки любых приложений а так же раз в сутки на всякий случай. В качестве хранилища, могут использоваться на выбор одна из нескольких CVS. Наиболее популярные из них это Bazaar и Git. В Ubuntu обычно по умолчанию используется первая а RHEL-подобных дистрибутивах в основном Git, хотя, это не принципиально.
Установка
Прелесть этой маленькой утилиты в том, что для ее установки и настройки требуется выполнить буквально несколько простых команд при этом работу которую она делает, сложно переоценить.
Для демонстрации примеров я будут использовать CentOS 6.5 а в роли CVS — Git.
Прежде необходимо подключить репозиторий EPEL;
wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm_x000D_ rpm -Uvh epel-release-6-8.noarch.rpm
Теперь можно устанавливать etckeeper;
yum install etckeeper
В маленьком списке зависимостей можно увидеть Git который будет использоваться по умолчанию.
После успешной установки стоит заглянуть в скромный конфигурационный файл /etc/etckeeper/etckeeper.conf, что бы убедиться в верности параметров.
В начале указываем VCS. Нужная уже выбрана по умолчанию.
#VCS=»hg»
VCS=»git»
#VCS=»bzr»
#VCS=»darcs»
Убираем знак комментария, если не хотим что бы etckeeper делал снимок /etc каждые сутки;
#AVOID_DAILY_AUTOCOMMITS=1
Убираем знак комментария, если не хотим что бы etckeeper делал снимок изменений /etc перед установкой пакетов;
#AVOID_COMMIT_BEFORE_INSTALL=1
На этом пожалуй наиболее интересные параметры заканчиваются остается лишь выполнить запуск etckeeper;
etckeeper init
Initialized empty Git repository in /etc/.git/
В результате будет создан пустой репозиторий Git — /etc/.git в который будут помещаться резервные копии.
Использование
Теперь когда etckeeper запущен, можно спокойно устанавливать новые пакеты или обновлять систему не заботясь о резервном копировании файлов конфигураций, плюс у вас будет ежедневная копия /etc на всякий случай.
Здесь можно было бы рассказать о том как откатиться к нужному снимку /etc и завершать статью. Но, мы ведь профессионалы и должны полностью изучить возможности инструмента и использовать его по максимуму.
Создание копии
После запуска etckeeper рекомендуется в ручную оправить содержимое /etc в репозиторий.
Делается это следующей командой;
etckeeper commit "initial commit"
Это называется commit — базовое понятие во всех системах контроля версий при котором все отличия отправляются в репозиторий. В нашем случае все содержимое /etc так как это первый запуск.
Теперь посмотрим текущий статус;
etckeeper vcs status
On branch master nothing to commit (working directory clean)
Это означает, что не каких изменений с последнего коммита не произведено.
Дабы расставить все по своим местам, необходимо понимать, что приведенные выше команды init, commit это фактически команды Git’a которые etckeeper передает ему в виде параметров.
Например;
etckeeper init = git init /etc
etckeeper vcs status = git status
Здесь, можно провести границу. Обвязка в виде etckeeper’а хороша для выполнения commit’ов автоматически при установкеобновлении ПО и раз в сутки. При работе в ручном режиме правильнее отказаться от посредника и использовать именно Git.
Первичная настройка
Прежде чем перейти к практическим примерам и активному использованию Git’a необходимо настроить ряд параметров, в первую очередь для нашего же удобства. Обычно это делается сразу же после его установки.
Так как Git это среда совместной работы где один и тот же файл может редактироваться несколькими пользователями необходима их идентификация. Для этого используется произвольное имя и e-mail. По умолчанию, эти параметры генерируются на основании имен компьютера и учетной записи пользователя. Но это не нормально и при каждом коммите вам об этом будет напоминаться. Поэтому сразу же зададим эти параметры.
git config --global user.name "Alex Rudenko"
git config --global user.email "a.rudenko@domain.com"
Так же можно задать используемый по умолчанию текстовый редактор;
git config --global core.editor <имя_редактора>
И определить какой утилитой выполнять сравнение файлов, если стандартный diff чем то не устраивает;
git config --global merge.tool <имя_утилиты>
Изменение файлов
Например изменим hostname в файле /etc/sysconfig/network и произведем соответствующие изменения в файле /etc/hosts.
А теперь посмотрим статус;
# git status_x000D_ _x000D_ ..._x000D_ # modified: hosts_x000D_ # modified: sysconfig/network_x000D_ (вывод сокращен)
В результате мы увидим имена файлов изменившихся, с момента последнего коммита;
Примечание: Для удобной работы с репозиторием /etc при помощи команды git необходимо предварительно перейти в каталог /etc (cd /etc) иначе, у всех команд придется дополнительно использовать параметр —git-dir /etc/.git.
А следующая команда покажет что конкретно в них изменено:
git diff
Плюсами и минусами а так же цветами отмечены соответствующие изминения. Отправим их в репозиторий;
git commit -av -m "Edit hostname and hosts"
-a — отправить в репозиторий все изменения, -v — выводить больше информации, -m — комментарий
Git отслеживает и коммитит изменения только тех файлов, что уже присутствуют в репозитории. Если вы создадите новый файл в директории /etc то утилиты status, diff нечего о нем не расскажут. Для этого его необходимо предварительно добавить в репозиторий.
git add <имя_файла>
Примечание: При установке пакетов, etckeeper добавляет новые файлы в репозиторий автоматически.
Установка пакетов
Перед установкой любого пакета, etckepper автоматически выполняет коммит за вас. Это позволит без болезненно откатиться к любым прежним версиям файлов если что то пойдет не так.
Например;
yum -y install mc
В самом конце листинга можно будет увидеть подобные строчки;
...._x000D_ Running Transaction_x000D_ etckeeper: pre transaction commit_x000D_ Installing : gpm-libs-1.20.6-12.el6.x86_64 1/2_x000D_ Installing : 1:mc-4.7.0.2-3.el6.x86_64 2/2_x000D_ etckeeper: post transaction commit_x000D_ Verifying : 1:mc-4.7.0.2-3.el6.x86_64 1/2_x000D_ Verifying : gpm-libs-1.20.6-12.el6.x86_64 2/2_x000D_ (вывод сокращен)
Просмотр изменений
Теперь когда сделано несколько коммитов, интересно взглянуть на их историю;
git log
В результате будет выведенна краткая информация по всем коммитам; уникальный идентификатор, дата, имя автора и комментарий.
git log --pretty=oneline
Выведет сокращенный вариант;
97c7ddf96569f6f1f8450271bfe9803748ac8ef5 add test2.txt_x000D_ eb4cf1ff683e007779ee9a5bcb61d28e33d99c5b committing changes in /etc after..._x000D_ 853353b3fb3dfb3903e92e46c8cc70efdfa05c71 saving uncommitted changes..._x000D_ 7e07823132d80266a5508e88b03c36bacffb1673 Edit hostname and host_x000D_ b8215712b225a293ec715afcaec9f0218c7fef3d Initial commit
так же можно просмотреть коммиты затрагивающие конкретный каталог;
git log /etc/sysconfig/*
Или вывести весь лог последнего коммита (-2 двух последних и так далее)
git log --summary -1
Откат изменений
Вернуться к последнему состоянию /etc;
git reset --hard
Вернуться к конкретному состоянию
git reset --hard eb4cf1f
eb4cf1f — это первые цифры уникального идентификатора коммита. Я указываю первые семь цифр для надежности но можно ограничиться и четырьмя.
Если все же решите вернуться в последнее(до возврата) состояние то необходимо;
1. посмотреть все коммиты через которые перепрыгнули;
git reflog_x000D_
_x000D_
206ba4a HEAD@{0}: 206ba4a: updating HEAD_x000D_
5d6d285 HEAD@{1}: commit: test3_x000D_
3d5b13a HEAD@{2}: commit: committing changes in /etc after yum run_x000D_
3ee4429 HEAD@{3}: commit: saving uncommitted changes in /etc prior to yum_x000D_
b0cf5c7 HEAD@{4}: commit: committing changes in /etc after yum run_x000D_
12c0fe8 HEAD@{5}: commit: hostname and hosts и перейти к любому из них(последний до текущего имеет №1)
git reset --hard 5d6d285
Так же можно вернуть любой из отдельных файлов из последнего комита;
git checkout /etc/hosts
или из конкретного;
git checkout 206ba4a /etc/hosts
Выводы
Это далеко не все возможности современной системы контроля версий. Но даже этих примеров достаточно, что бы понять на сколько полезным этот инструмент может быть администраторам. А такое простое средство как etckeeper поможет автоматизировать некоторые процессы и быть спокойнее в моменты когда что то пойдет не так.
Помогла ли вам статья?
