В какой степени управление версиями может помочь в системном администрировании?
В настоящее время я работаю над системой OpenBSD с целью построить себе брандмауэр и некоторые другие биты и бобы.
Поскольку это довольно экспериментально (я OpenBSD n00b, и я уже разгромил свою систему 3 или 4 раза), мне интересно, какой опыт есть у других, чтобы сделать часть или всю файловую систему (я имею в виду, в частности, /etc) рабочей копией некоторых VCS или других.
-
Это хорошая идея?
-
Меня особенно интересует, какие именно ВКС люди привыкли к этому. Я рассматриваю subversion, bazaar и git; это не будет общий репозиторий, поэтому меня, возможно, больше интересует базовая функциональность vcs, чем аргумент распределенный или нет.
-
Я также хотел бы услышать о воображаемых или реальных ловушках, которые люди обнаружили. Я могу себе представить, что сохранение прав собственности на файлы и разрешений требует тщательного обдумывания!
-
И, конечно же, любые альтернативные подходы, не связанные с VCS
7 ответов:
Для того, что вы делаете, я бы предложил вместо того, чтобы начинать с 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
Теперь наша папка еще не является рабочей копией, поэтому мы должны сделать ее. Можете ли вы создать .файл svn? Он не может:)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
cd /root/scripts mv svnrepo svnrepo.old svn checkout svn+ssh://replica@sparky/home/replica/svnrepo
Теперь попробуйте изменить файл в etc, например hosts.
Снова Rsync. Вы должны получить только измененный файл, который скопирован в файл /etc / hosts.
Теперь вы можете совершить:
Есть еще кое-что напоследок. Если ты нужен файл, чтобы быть приняты подрывной деятельности, он должен быть добавлен. Например, если вы создадите новый файл в /etc, он не будет сохранен по умолчанию.svn commit -m "backup 1" /root/scripts/svnrepo
Что же делать?
Тогда вы должны создать свой собственный сценарий.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, когда смогу выбраться из-под текущей рабочей груды.