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