Власть над конфигурацией. Etckeeper и Git

Наверное каждый слышал о рекомендации выполнять резервное копирование конфигурационных файлов перед их редактированием. Так же бывают случаи когда обновление пакета или системы в целом приводит к перезаписи файлов с настройками в результате чего что то перестает работать. Если вам известны подобные проблемы то продукт 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 поможет автоматизировать некоторые процессы и быть спокойнее в моменты когда что то пойдет не так.

Помогла ли вам статья?

Рейтинг
( Пока оценок нет )
iVirt-it.ru
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: