LXF121:VCS
(Новая: ==''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.
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
Остальные команды, поддерживаемые 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 часов.