В какой степени управление версиями может помочь в системном администрировании?


В настоящее время я работаю над системой OpenBSD с целью построить себе брандмауэр и некоторые другие биты и бобы.

Поскольку это довольно экспериментально (я OpenBSD n00b, и я уже разгромил свою систему 3 или 4 раза), мне интересно, какой опыт есть у других, чтобы сделать часть или всю файловую систему (я имею в виду, в частности, /etc) рабочей копией некоторых VCS или других.

  • Это хорошая идея?

  • Меня особенно интересует, какие именно ВКС люди привыкли к этому. Я рассматриваю subversion, bazaar и git; это не будет общий репозиторий, поэтому меня, возможно, больше интересует базовая функциональность vcs, чем аргумент распределенный или нет.

  • Я также хотел бы услышать о воображаемых или реальных ловушках, которые люди обнаружили. Я могу себе представить, что сохранение прав собственности на файлы и разрешений требует тщательного обдумывания!

  • И, конечно же, любые альтернативные подходы, не связанные с VCS

7 4

7 ответов:

Здесь у вас есть подробная редакция о том, как поставить /etc/ под контроль версий с помощью git.

Еще один пошаговый метод.

Для того, что вы делаете, я бы предложил вместо того, чтобы начинать с OpenBSD, вы начинаете с дистрибутива, где большая часть работы уже сделана, как pfsense.

Что касается самого VCS, вы можете рассмотреть mercurial , который успешно используется этими проектами

Я не думаю, что кто-то упоминал etckeeper еще.

Он хранит /etc в репозитории (Git (default), mercurial или bzr). Он решает проблемы с сохранением прав собственности на файлы, разрешений и пустых каталогов. Он может интегрироваться с пакетом managemnet (по крайней мере, с apt) для автоматической фиксации изменений в /etc, которые происходят во время установки нового пакета. Очень хорошо, если установка борется с вашими собственными изменениями, просто откатите назад.

Я успешно использую его в Ubuntu для какое-то время.

Больше, чем просто файлы конфигурации в систему управления версиями, я предлагаю использовать систему управления конфигурацией, такие как шеф - и кукольный, чтобы управлять содержанием, разрешения и другие детали конфигурационных файлов, таких как перезапуск приложения в случае конфигурационный файл изменения, и управлять этими файлов в Git/Subversion и/yourfavoriteVCS.

Я читал что-то об этом в "Gnu/Linux Magazine France". Парень использует rsync из /etc для root/, а затем сохраняет его через subversion, не создавая рабочую копию.

Я собираюсь немного процитировать журнал.

Итак, в Примере сервер работает под управлением freeBSD и является" sparky", в то время как машина, которую нужно сохранить, находится под debian и является"репликой". Создайте пользовательскую "реплику".

В файле /usr / local / etc / ssh / sshd_config добавить:

Match User replica
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/svnserv -t -r /home/replica/svnrepo -tunnel-user=replica

Создание репозитория

Спарки # svnadmin create / home / replica / svnrepo

Права на исправление:

sparky # chown -R replica:nogroup /home/replica
sparky # chown -R o-rwx /home/replica
sparky # chown -R g-rwx /home/replica

Сторона клиента:

Установить subversion

replica # mkdir -p /root/scripts/svnrepo
replica # rsync -av /etc /root/scripts/svnrepo

export SVN_SSH ="ssh -i /root/.ssh/id_rsa"
svn import -m "replica config files" /root/scripts/svnrepos svn+ssh://replica@sparky/home/replica/svnrepo
Теперь наша папка еще не является рабочей копией, поэтому мы должны сделать ее. Можете ли вы создать .файл svn? Он не может:)
cd /root/scripts
mv svnrepo svnrepo.old
svn checkout svn+ssh://replica@sparky/home/replica/svnrepo

Теперь попробуйте изменить файл в etc, например hosts.

Снова Rsync. Вы должны получить только измененный файл, который скопирован в файл /etc / hosts.

Теперь вы можете совершить:

svn commit -m "backup 1" /root/scripts/svnrepo
Есть еще кое-что напоследок. Если ты нужен файл, чтобы быть приняты подрывной деятельности, он должен быть добавлен. Например, если вы создадите новый файл в /etc, он не будет сохранен по умолчанию.

Что же делать?

svn status /root/scripts/svnrepo | grep -e '^!' | awk '{ print $2 }' | xargs -r svn delete 
svn status /root/scripts/svnrepo | grep -e '^?' | awk '{ print $2 }' | xargs -r svn add
Тогда вы должны создать свой собственный сценарий.

Надеюсь, это поможет.

(gtg, я буду редактировать позже, чтобы установить названия и так один, если никто не делает)

Все в /etc на каждом сервере, которым я управляю (300 + и подсчет), находится под Mercurial. Почему?

  • его легко использовать для тех, кто когда-либо использовал SVN или CVS (если у вас нет, у вас нет бизнеса, занимающегося бизнесом в /etc на моих производственных машинах)
  • это позволяет легко переносить изменения из конфигурации одного сервера во множество других
  • я могу откатиться, когда у других администраторов есть мозговой пердеж, быстро

Git был просто слишком большой силой для слишком малого проблема в данном случае. Поскольку HG является DVCS, коммиты и откаты являются чистыми и легкими. Я также использую HG дляуправления большинством моих веб-сайтов .

Это не только для исходного кода :) другой более простой вариант-использовать какую-то файловую систему управления версиями, которая делает снимки при записи (CoW), а DVCS намного проще.

Обратная связь: что я в итоге сделал

(@Aif, Спасибо за мягкое напоминание, что мои хорошие манеры были немного пропущены)

Я пошел с /etc в качестве репозитория git, но поскольку я все еще немного обеспокоен этим (я, а не git), я делаю gitwork вручную.

В качестве побочного эффекта я начал работать над небольшим проектом, чтобы оценить, бок о бок, subversion, git, bazaar, mercurial, monotone, darcs и fossil, хотя и в более общем контексте управления версиями (слияния и поглощения). подобный).


Мои реакции на ваши ответы

Спасибо всем за вашу помощь. Мне было трудно выбрать, какой ответ принять, поэтому, если это не ваш, пожалуйста, поверьте мне, я тоже оценил ваш.

@Луис Мельгратти

Луис, спасибо за пару отличных рекомендаций. Я принял ваш ответ как самый полезный.

@Конрад

Конрад, я ценю оба твоих предложения.

Я непременно это сделаю. исследуйте pfsense , хотя одна из моих целей в этом состоит в том, чтобы действительно испачкать руки, а также построить брандмауэр, поэтому важно "делать, а не приобретать".

Что касается Mercurial, я не включил его в свой список, потому что я уже пробовал его (ранее), и я чувствовал, что мне "нравится" bazaar больше, в то время как git, кажется, на первый взгляд, имеет большую власть (которая, по общему признанию, мне может и не понадобиться). Мой "главный" VCS в настоящее время-Subversion, хотя я не уверен, что это хороший ответ для этот случай. Отсюда и список из трех.

(теперь я взглянул на pfsense и запустил его в своей сети. Очень хорошо, но я вовсе не уверен, что мои руки хоть немного испачкаются...)


@АиФ

Спасибо, АиФ. Я определенно попытаюсь это сделать, хотя подозреваю, что в итоге получу Гита.


@тинкертим

Благодарю вас за ваши мысли о Mercurial, к которым я теперь планирую вернуться, хотя я очень доволен Восточный базар.


@Per Wiklander

Спасибо за очень интересное предложение! Я определенно собираюсь взглянуть на etckeeper, когда смогу выбраться из-под текущей рабочей груды.