Материал из Linuxformat.

Содержание 1 Git: /etc под контролем 1.1 Машина времени для ваших файлов 1.2 Приступаем 1.3 Используем etckeeper 1.4 Снимки по расписанию 1.5 Другие решения 1.6 Памятка пользователя Git

Git: /etc под контролем

Хороший администратор всегда сохранит резервную копию конфигурационного файла, прежде чем внести в него изменения. Оказывается, это можно делать автоматически, поясняет Eвгений Зобнин.

Любой, кто не брезгует редак тированием системных кон­фигурационных файлов вручную, наверняка сталкивал­ся с ситуацией, когда после очередного подкручивания настроек программа или да же вся система начина ли вести себя некорректно. Обычно проблему легко решить, просто вернув кон­фигурацию в первоначальное состояние, но что если изменения были произведены уже давно и вы не помните, что и где испра­вили, а странности в поведении системы заметили только сей­час? А если вы новичок и отредак тирова ли целую пачку файлов вслепую, следуя какому­то устаревшему HowTo и не до конца по­нимая все тонкости настройки Linux? Системным администрато­рам в этом плане еще сложнее: нужный конфигурационный файл мог быть исправлен другим человеком, который да же и не поду­мал сообщить о произведенных изменениях. Борьба с ошибка­ми настройки может стать настоящей мукой для неподготовлен­ного пользователя, а для некоторых выливается в полную пере­установку операционной системы.

Существует несколько способов борьбы с описанной про­блемой, самый эффективный из которых – перевести ката­лог /etc, содержащий основные конфигурационные файлы, под управление системы контроля версий. Да­да, именно той, которую используют программисты для фиксации изменений в коде. Система контроля версий позволит оставлять коммента­рий для каждого действия, произведенного над каталогом /etc, и вести историю всех изменений; она обеспечит возможность бы­ строго отката любого количества правок; она легка в установке и проста в использовании.

Машина времени для ваших файлов

Система контроля версий (Version Control System, VCS) работа­ет по принципу моментальных снимков. Вы вносите некоторое количество изменений в свои файлы, а затем просто вызываете команду, которая «приказывает» VCS сделать снимок рабочего каталога и поместить его в специальное хранилище, называемое репозиторием. Если в будущем вы поймете, что совершили ошиб­ку, и прошлый вариант был лучше текущего, VCS позволит вер­нуть файлы к тому состоянию, в котором они на ходились на момент «фотографирования». Пользуясь ею, вы будете увере­ны, что непоправимых ошибок не бывает и любой, даже удален­ный, файл до сих пор существует в репозитории.

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

Приступаем

В качестве VCS мы будем использовать Git, созданную самим Линусом Торвальдсом [Linus Torvalds] – мы говорили о ней в LXF116 и 120. Она быстра, удобна и, что самое важное, не требует создания выделенного репозитория: он может храниться прямо в рабочем каталоге, в нашем случае – /etc. Чтобы установить Git, просто найдите его в графическом менеджере пакетов и нажмите кнопку Install [Установить] или воспользуйтесь командой apt-get install git-core (Debian/Ubuntu) или yum install git (Fedora/Red Hat).

Перевести каталог конфигурационных файлов на использование Git очень просто: достаточно создать новый репозиторий и добавить в него все содержимое /etc (то есть сделать первый снимок). Первая операция выполняется с помощью двух простых команд:

# cd /etc
# git init

Чтобы никто, кроме root, не смог заглянуть в наш репозиторий и выудить из него ценную информацию (пользовательские пароли, содержимое файла /etc/sudoers и т. д.), лишим всех сторонних пользователей любых прав в отношении хранилища:

# chmod og-rwx .git

Теперь мы должны добавить в репозиторий конфигурационные файлы, но в каталоге /etc всегда имеется несколько файлов, которые генерируются динамически или создаются для временных целей. Это может быть, например, файл /etc/mtab, содержащий список всех смонтированных в данный момент файловых систем, /etc/motd («сообщение дня»), обновляемый во многих системах в процессе загрузки, или кэш /etc/blkid.tab, используемый одноименной командой. В Debian/Ubuntu это еще и все файлы с расширением .dpkg-new и .dpkg-old. Такие файлы могут создать (и обязательно создадут) большую путаницу между содержимым репозитория и актуальным состоянием каталога /etc, поэтому мы добавим их имена в «список игнорирования» Git:

# cat > .gitignore << EOF
*~
*.dpkg-new
*.dpkg-old
blkid.tab
mtab
motd
ld.so.cache
asound.state
adjtime
EOF

Теперь можно зафиксировать содержимое /etc в хранилище:

# git add .
# git commit -a -m «Первый снимок»

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

# git commit -a -m «Описание внесенных изменений»

Внеся несколько изменений, вы сможете посмотреть их список с помощью команды log:

# git log

Для отмены внесенных изменений воспользуйтесь командой git checkout, которая вернет состояние каталога к указанной точке:

# git checkout «@{30 minutes ago}»

Вы можете задать также и абсолютное время или конкретный снимок, ключ которого можно выудить из строчки commit вывода команды git log. Главное, не забудьте после этого синхронизировать состояние каталога с репозиторием с помощью команды git commit.

Остальные команды, поддерживаемые Git, вам, скорее всего, никогда не понадобятся, ведь все изменения, производимые пользователем над каталогом /etc, сводятся к простому редактированию файлов. Другое дело – пакетные менеджеры, которые могут добавить в систему конфигурационный файл устанавливаемой программы или удалить уже существующий. Чтобы избежать описанных выше проблем с несоответствием репозитория реальному содержимому каталога /etc, последний придется обновлять каждый раз после установки нового пакета:

# apt-get install tuxracer
# cd /etc
# git add .
# git commit -a -m “Изменения внесены пакетом tuxracer”

Утомительно и неудобно, не спорю. К счастью, есть способ получше.

Используем etckeeper

Набор скриптов под названием etckeeper («хранитель etc») создан с целью избавить пользователей от необходимости обновлять репозиторий /etc после каждой установки, удаления или обновления пакетов. Он интегрируется с системами управления пакетами дистрибутивов Debian/Ubuntu, Fedora/Red Hat, Arch Linux и выполняет все необходимые действия автоматически.

Пакет etckeeper уже доступен для Debian и Ubuntu, поэтому, чтобы начать использовать его в этих дистрибутивах, достаточно выполнить следующую последовательность действий:

# apt-get install etckeeper
# etckeeper init
# cd /etc
# git commit -m “Первый снимок”

Теперь вы сможете спокойно работать с каталогом /etc. После внесения изменений в конфигурационные файлы по-прежнему придется обновлять репозиторий, но установка и удаление пакетов не потребуют каких-либо дополнительных действий: все изменения будут фиксироваться автоматически. Если в один прекрасный день вы поймете, что контроль версий конфигурационных файлов вам не нужен, просто перейдите в каталог /etc и выполните команду etckeeper uninit, и репозиторий Git исчезнет с вашего диска.

Снимки по расписанию

Если же необходимость запуска специальных команд после каждого редактирования конфигурационных файлов вас пугает, то вы можете настроить систему на создание ежечасных снимков каталога /etc. Сделать это просто – достаточно только написать совсем небольшой скрипт, который будет запускаться демоном cron:

#!/bin/sh
cd /etc
git add .
git commit -m “Автоматический снимок от: `date`”

Поместите его в файл /etc/cron.hourly/etc-git, установите бит исполнения (chown a+x /etc/cron.hourly/etc-git), и вы будете получать новый снимок системных конфигурационных файлов каждый час.

Другие решения

Идея хранения истории изменений конфигурационных файлов далеко не нова. Множество разработчиков в разные времена предлагали свои варианты ее реализации. Еще до появления децентрализованных систем управления версиями файлы /etc было принято хранить в CVS, что создавало некоторое неудобство ввиду ее требований к выделенному репозиторию. Не меньшей популярностью пользовались решения, основанные на файловых системах с функцией снимков состояния, таких как backupfs (http://sourceforge.net/projects/backupfs). Сегодня некоторые разработчики и даже компании предлагают комплексные решения по управлению конфигурацией серверов, среди которых можно выделить Puppet (http://reductivelabs.com/products/puppet/) – мощную, но сложную систему для управления конфигурациями, и IsiSetup (http://www.isisetup.ch/) – обертку для системы контроля версий Subversion (о которой мы говорили в LXF118 и 120), упрощающую многие задачи поддержания репозитория в актуальном состоянии. Несмотря на все это, большинство продвинутых пользователей предпочитают использовать для ведения истории конфигурационных файлов именно Git.

Памятка пользователя Git

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

• git whatchanged -5 – кратко о последних пяти изменениях;
• git diff HEAD^ – различия межу рабочим каталогом и репозиторием;
• git diff “@{2009-05-05 9:00:00}” – все изменения, произошедшие с определенного момента времени;
• git diff “@{12 hours ago}” – что изменилось за последние 12 часов.