Журнал LinuxFormat - перейти на главную

LXF121:VCS

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая: ==''Git'': /etc под контролем== : Хороший администратор всегда сохранит резервную копию конфигурационного ф...)
 
(викификация, оформление, иллюстрация)
 
Строка 16: Строка 16:
 
===Машина времени для ваших файлов===
 
===Машина времени для ваших файлов===
  
Система контроля версий (Version Control System, VCS) работа­ет по принципу моментальных снимков. Вы вносите некоторое количество изменений в свои файлы, а затем просто вызываете команду, которая «приказывает» ''VCS'' сделать снимок рабочего каталога и поместить его в специальное хранилище, называемое репозиторием. Если в будущем вы поймете, что совершили ошиб­ку, и прошлый вариант был лучше текущего, ''VCS'' позволит вер­нуть файлы к тому состоянию, в котором они на ходились на момент «фотографирования». Пользуясь ею, вы будете увере­ны, что непоправимых ошибок не бывает и любой, даже удален­ный, файл до сих пор существует
+
Система контроля версий (Version Control System, ''VCS'') работа­ет по принципу моментальных снимков. Вы вносите некоторое количество изменений в свои файлы, а затем просто вызываете команду, которая «приказывает» ''VCS'' сделать снимок рабочего каталога и поместить его в специальное хранилище, называемое репозиторием. Если в будущем вы поймете, что совершили ошиб­ку, и прошлый вариант был лучше текущего, ''VCS'' позволит вер­нуть файлы к тому состоянию, в котором они на ходились на момент «фотографирования». Пользуясь ею, вы будете увере­ны, что непоправимых ошибок не бывает и любой, даже удален­ный, файл до сих пор существует
 
в репозитории.
 
в репозитории.
  
Изначально ''VCS'' применя­лась только программистами для совместной работы над про­ектом, и да же сама идея кон­троля версий принадлежит про­
+
Изначально ''VCS'' применя­лась только программистами для совместной работы над про­ектом, и да же сама идея кон­троля версий принадлежит про­программистам. Сегодня же ''VCS'' используют многие: от писателей и журналистов, следящих с ее помощью за своими текстами, до системных администраторов, использующих ''VCS'' для контроля над конфигурационными файлами.
 +
 
 +
===Приступаем===
 +
 
 +
В качестве ''VCS'' мы будем использовать ''Git'', созданную самим Линусом Торвальдсом [Linus Torvalds] – мы говорили о ней в [[LXF116:Git|LXF116]] и [[LXF120:Контроль_версий|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''.
 +
 
 +
{{Врезка|Содержание=[[Изображение:LXF121_29_1.jpg|300px]]Помимо консольной, у ''Git'' есть и графическая ипостась.|Ширина=300px}}
 +
 
 +
Остальные
 +
команды,
 +
поддерживаемые
 +
''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:Subversion|LXF118]] и [[LXF120:Контроль_версий|120]]), упрощающую
 +
многие
 +
задачи
 +
поддержания
 +
репозитория
 +
в актуальном
 +
состоянии.
 +
Несмотря
 +
на все это, большинство
 +
продвинутых
 +
пользователей
 +
предпочитают
 +
использовать
 +
для ведения
 +
истории
 +
конфигурационных
 +
файлов
 +
именно
 +
''Git''.
 +
 
 +
===Памятка пользователя ''Git''===
 +
 
 +
Иногда
 +
возникает
 +
необходимость
 +
не просто
 +
восстановить
 +
конфигурационный
 +
файл,
 +
но и узнать,
 +
какие
 +
изменения
 +
привели
 +
к нежелательным
 +
для системы
 +
последствиям.
 +
В этом
 +
вам помогут
 +
следующие
 +
несколько
 +
команд:
 +
 
 +
* '''''git whatchanged -5''''' – кратко о последних пяти изменениях;
 +
* '''''git diff HEAD^''''' – различия межу рабочим каталогом и репозиторием;
 +
* '''''git diff “@{2009-05-05 9:00:00}”''''' – все изменения, произошедшие с определенного момента времени;
 +
* '''''git diff “@{12 hours ago}”''''' – что изменилось за последние 12 часов.

Текущая версия на 22:42, 19 июля 2010

Содержание

[править] 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 часов.
Персональные инструменты
купить
подписаться
Яндекс.Метрика