контроль версий для / etc под * BSD

Какие готовые решения существуют для /etcконтроля версий, для различных подразделений? Под ключ не обязательно подразумевается часть базовой установки, но следующие функции были бы хороши:

• подключается к командам VCS для управления метаданными (владение, разрешения);
• интеграция с менеджером пакетов (автоматический запуск до и после установки, интеллектуальная обработка обновлений);
• относиться к версиям исходных файлов как к ветке;
• предварительно заполненный список игнорирования;
• поддержка нескольких базовых VCS (особенно распределенных).

Я использую etckeeper под Debian и производными. У него есть все перечисленные выше функции, за исключением того, что он не отслеживает вышестоящие версии. Я хотел бы узнать об альтернативах, особенно на * BSD.

В Gentoo инструмент для управления изменениями в / etc, вызванными пакетами (называемый dispatch-conf), поддерживает rcs для отслеживания изменений, но это не очень эффективно.

Я склоняюсь к версии моего / etc через git, тем более что, используя разные ветки, я могу сохранять свои / etc как можно более похожими в разных дистрибутивах, сохраняя как можно больше вещей в одном месте (для некоторых областей, которые явно не работают, конфигурация apache например, действительно отличается в разных дистрибутивах). Это работает так:

У меня есть masterрепозиторий с файлами конфигурации по умолчанию. Теперь я вступаю в контакт с новым дистрибутивом, поэтому создаю новую ветку на основе моей masterветки на основе имени дистрибутива (в данном примере debian). Debian хранит некоторые файлы конфигурации в месте, отличном от моего, masterпоэтому я делаю a git mv file new_loc. И все хорошо. Я переключаюсь назад masterи изменяю этот файл, потому что я добавил определенную директиву config, когда я объединяюсь masterс моей debianветкой, перемещенный файл изменяется, так что я могу просто изменить большинство вещей в моей masterветке и просто слить изменения в моем «дистрибутиве» ветви (как правило, они, как правило, представляют собой смесь веток распределения и назначения, сервер Debian, очевидно, имеет некоторые отличия от рабочей станции Debian, но функции все еще работают).

Так что в основном у меня есть «общая конфигурация», masterи (если говорить в терминах объектно-ориентированного программирования) она наследуется в мои ветви (которые также могут наследовать друг от друга).

Кроме того, gitмеханизмы «выбора вишен» (в данном случае изменения в / etc /) были весьма полезны для меня в тех случаях, когда мне нужны были только части определенной конфигурации.

Теперь к некоторым из ваших идей:

• Если бы мне потребовалась дополнительная интеграция с менеджером пакетов, я бы использовал для этого сценарии-оболочки (на данный момент я не использую).
• обращение с версиями выше по течению, как с веткой, будет работать нормально git, это просто еще одна ветка, в которую вы иногда сливаетесь (частично)master
• Список игнорирования в git - это файл .gitignore в вашем репо, так что он покрыт.

Я использовал fossilдля этого с некоторым успехом. Смотрите мой пост о Fossil для получения дополнительной информации. Я также использовал инструмент, etcupdateкоторый называется для перемещения между обновлениями, а не для отслеживания изменений. Я полагаю, что это было предназначено, чтобы быть сопутствующим инструментом для freebsd-updateодной точки Я не уверен в его статусе в настоящее время, но он работает на моих RELEASE-8.*системах.

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017927.html http://people.freebsd.org/~jhb/etcupdate/

Есть инструмент etckeeper, я понятия не имею, насколько он хорош.

etckeeper - это набор инструментов, позволяющих хранить / etc в репозитории git, mercurial, darcs или bzr. Он подключается к apt (и другим менеджерам пакетов, включая yum и pacman-g2) для автоматической фиксации изменений, внесенных в / etc во время обновления пакетов. Он отслеживает метаданные файла, которые обычно не поддерживаются системами контроля версий, но это важно для / etc, например, разрешения для / etc / shadow. Он достаточно модульный и настраиваемый, а также простой в использовании, если вы понимаете основы работы с контролем версий.

Я также не знаю, можно ли заставить его работать на * BSD, я подозреваю, что это возможно, но это не будет поддерживаться с портами из коробки.