Как управлять / etc с помощью контроля версий, используя Etckeeper на CentOS 7

В экосистеме Linux необходимо периодически устанавливать, поддерживать и обновлять программное обеспечение. Однако отслеживание изменений, внесенных в локальные файлы конфигурации, все еще необходимо. В отличие от старого режима создания копий файлов конфигурации перед внесением изменений, etckeeper позволяет отслеживать изменения, используя репозиторий Git, Mercurial, Bazaar или Darcs, как вы это делали бы в проекте разработки программного обеспечения.

Кроме того, etckeeper легко интегрируется с yum для автоматической фиксации изменений, внесенных в содержимое каталога + / etc + при обновлении пакетов. Это позволит вам вернуться к предыдущим версиям ваших файлов конфигурации, если вы захотите или захотите это сделать.

Чтобы следовать этому уроку, вам понадобится:

etckeeper отслеживает только права доступа к файлам, метаданные и изменения. Он не предоставляет готовых инструментов для восстановления файлов, поэтому необходимо понимание основ системы контроля версий.

В этой статье мы будем использовать Git - VCS по умолчанию, которую использует etckeeper. Если вы хотите освежить память о Git и управлении версиями, вы можете проверить this этого учебного пособия. Хотя вы не будете использовать Git напрямую в этом руководстве, вы можете запускать специфичные для Git команды через etckeeper.

На этом шаге мы установим etckeeper.

Во-первых, вам нужно включить EPEL (дополнительные пакеты для корпоративного Linux) на вашем сервере CentOS 7, потому что это репозиторий, содержащий etckeeper.

Затем установите etckeeper.

Git поставляется с CentOS 7 по умолчанию, поэтому нам не нужно его устанавливать.

После того, как вы установили etckeeper, следующим шагом будет обновление файла конфигурации + / etc / etckeeper / etckeeper.conf +.

Сначала откройте файл конфигурации с помощью Nano или вашего любимого текстового редактора.

Ниже приведены основные переменные, которые необходимо настроить, чтобы etckeeper работал правильно. Не стесняйтесь оставлять остальные настройки закомментированными.

Во-первых, под комментарием + # VCS для использования. + Убедитесь, что + VCS =" git "+ не закомментировано (т.е. в начале строки нет + # +). По умолчанию эта опция уже не будет прокомментирована, поскольку git - это VCS по умолчанию, используемая установками etckeeper в CentOS 7.

Если вы хотите запретить etckeeper автоматически вносить изменения один раз в день, убедитесь, что + AVOID_DAILY_AUTOCOMMITS = 1 + не закомментировано. Чтобы решить, хотите ли вы установить это, вы должны подумать о том, часто ли изменяются ваши файлы конфигурации системы (например, условия тестирования часто меняются каждый день). Если это так, вы должны закомментировать эту строку; в противном случае вы можете оставить комментарий.

Если вы хотите, чтобы установка yum прервалась при наличии незафиксированных изменений в + / etc +, обязательно раскомментируйте + AVOID_COMMIT_BEFORE_INSTALL = 1 +. Это потребует ручной фиксации перед использованием yum для установки пакетов. В противном случае оставьте его закомментированным, и yum автоматически передаст обновленные файлы перед запуском установки. Этот выбор полностью зависит от вас; это в значительной степени зависит от вашей среды и количества изменений. Это очень похоже на предыдущий пример, за исключением того, что на этот раз это будет зависеть от частоты, с которой вы устанавливаете пакеты.

Когда вы закончите обновление параметров, сохраните и закройте файл.

На этом шаге мы инициализируем Git-репозиторий в + / etc +.

Сначала перейдите в каталог + / etc +.

Затем инициализируйте репозиторий, выполнив следующую команду.

Вы должны получить следующее сообщение:

Теперь вы должны увидеть каталог + .git и файл` + .gitignore` внутри + / etc. Например, если вы запустите следующую команду:

Вы должны увидеть эти строки, включенные в вывод:

Каталог + .git + содержит несколько файлов конфигурации и описания, а также другие подкаталоги, предназначенные для использования самого Git. Файл + .gitignore +, в котором указаны явно неотслеживаемые файлы, которые git должен игнорировать, предназначен для полного управления etckeeper. Не рекомендуется редактировать его вручную, за одним исключением.

Если есть определенные файлы, которые вы не хотите отслеживать с помощью контроля версий, вы можете добавить их в файл .gitignore вручную. Чтобы остановить отслеживание файла, сначала откройте + .gitignore + для редактирования.

В последней строке файла будет читаться + # end раздел, управляемый etckeeper +. Добавьте имена файлов, которые вы хотите игнорировать, по одному на строку, над этим.

Затем сохраните и закройте файл.

Кроме того, вам нужно будет удалить эти файлы из кэша, который в данный момент находится под управлением git, так как вы ранее инициализировали локальный репозиторий.

Повторите приведенную выше команду для всех файлов, которые вы ранее добавили в + .gitignore +.

На этом шаге мы зафиксируем наш начальный + / etc +.

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

Затем вы должны увидеть выведенный список файлов, сохраняемых в вашем хранилище, как показано ниже (усечено):

На этом шаге мы внесем некоторые изменения в файл в + / etc + и зафиксируем их. На следующем шаге мы вернем эти изменения.

Сначала внесите изменения в содержимое файла по вашему выбору. Например, вы можете добавить новый хост к вашему локальному разрешению имен, добавив строку, состоящую из IP-адреса и связанного с ним имени хоста в конце + / etc / hosts +.

Сначала откройте файл.

Затем добавьте следующую строку в конец файла.

Сохраните и закройте файл. Теперь давайте примем это изменение.

Наконец, измените права доступа к файлу.

И измените его владельца (обязательно замените * sammy * своим именем пользователя).

Вы можете проверить текущие права и владельца + / etc / hosts +.

Вывод должен выглядеть так:

Теперь давайте проверим возможности восстановления etckeeper - не только файла и его содержимого, но также его прав доступа и владельца.

Во-первых, перечислите коммиты, которые вы уже сделали.

Первый столбец выходных данных представляет собой хэш SHA-1, который уникальным образом идентифицирует фиксацию; второе - это описание, которое вы использовали при отправке изменений ранее.

Ваш вывод должен выглядеть примерно так, с разными хешами.

Запишите хэш каждого коммита. Вы будете использовать их для возврата к этому предыдущему состоянию.

Давайте вернемся к + / etc / hosts + к тому, как он выглядел до того, как мы начали этот урок. Замените символы красного цвета на хэш SHA-1, соответствующий вашему первому коммиту. Обратите внимание, что вам не нужно указывать всю хеш-строку SHA-1; несколько символов, которые однозначно идентифицируют это, сделают.

Теперь мы можем проверить содержимое, разрешения и владельца + / etc / hosts +, чтобы убедиться, что они были изменены обратно.

Посмотрите на последние несколько строк файла.

Должен дать вам такой вывод, в котором отсутствует строка +192.168.0.2 node01 +, которую мы добавили, как и ожидалось.

Проверьте текущие права и владельца + / etc / hosts + еще раз.

Вы увидите вывод, который выглядит следующим образом.

Содержимое файла было восстановлено правильно, а также права доступа и владельца.