Какую систему VCS проще всего использовать для отслеживания / и т.д.? Какие проблемы возникают при хранении каталога etc в системе управления версиями, передовой опыт? Должен ли я использовать централизованную или распределенную VCS?
Вы могли бы использовать etckeeper для его обработки, что позволит вам использовать git, mercurial, darcs или bzr для репозитория.
Использовать etckeeper сделать это за вас. Для этого есть много причин:
Я считаю, что git лучше всех справится с этой задачей (хотя Mercurial, вероятно, также подойдет). Простой "git init" в / etc, и вы в пути. После этого просто добавьте файлы, которые вам интересны, и каждый раз, когда они изменятся, вы можете зарегистрировать их. Вы даже можете настроить cron для автоматической проверки при каждом изменении (хотя тогда вы не получите журнал файлы). Вы также можете протолкнуть репозиторий, если хотите установить вторую машину с теми же конфигурациями, что и первая, или просто в качестве резервной копии.
Когда я начал заниматься системным администрированием, rcs был предпочтительным методом для / etc. Затем последовала CVS, затем SVN. Подозреваю, что когда появится что-то новое, я переключусь на это. :) Но с каждой новой парадигмой в VCS моя жизнь на самом деле становилась легче.
Я согласен с Джедбергом, но делаю обратное. Используйте репозиторий git, но создайте .gitignore, игнорируя все файлы, а затем добавьте отмену игнорирования для файлов, которые вам нужны. По крайней мере, так ваш статус git не будет постоянно грязным.
то есть: .gitignore *! hosts! resolv.conf
и т.д...
Джон
Без каких-либо религиозных намерений: я настоятельно рекомендую использовать распределенную VCS, предпочтительно Bazaar. Это потому что:
apt-get install bzr)cd /etc bzr init . bzr add . bzr commit . -m "Initial configuration"
Git и Mercurial - два других участника (как указывалось в других ответах), но им не хватает возможности отправить на удаленный сервер без настройки (по крайней мере, пока).
Я бы не стал управлять всем / etc в системе контроля версий. Причина в том, что большая часть содержимого / etc, вероятно, не сильно изменится со временем. Инструменты управления пакетами будут управлять большим количеством файлов в / etc, и обновление пакетов может вызвать интересные конфликты с VCS.
Вместо этого я бы использовал конфигурация управление система, которая управляет различными компонентами и пакетами моего сервера (серверов), используя шаблоны и статические файлы (где применимо) для настройки служб и параметров, которые хранят файлы в / etc (и в других местах). Я бы сохранил все это в системе контроля версий, и лично я предпочитаю Git, потому что как системный администратор, «типичные» рабочие процессы Git имеют для меня больше смысла, чем Subversion (или CVS). Децентрализация в Git делает для меня огромную победу в системном администрировании.
в дополнение ко всем советам, приведенным здесь ранее (которые почти полностью описывают то, что я делаю), я только что обнаружил тигр для меня. управление и т.д. с помощью git с использованием cmdline сводило меня с ума, и изменения быстро накапливались, и я не проявлял никакого желания позаботиться о них. просто случайно поискав графические интерфейсы git, я заметил, что существует основанный на ncurses, который называется tig.
теперь я действительно с нетерпением жду возможности управлять своими / etc!