web-dev-qa-db-ja.com

* BSDでの/ etcのバージョン管理

/etcをさまざまなユニスの下でバージョン管理下に置くために、どのようなターンキーソリューションが存在しますか？ターンキーは必ずしも基本インストールの一部を意味するわけではありませんが、次の機能があれば便利です。

  • メタデータ（所有権、権限）を管理するためにVCSコマンドにフックします。
  • パッケージマネージャーとの統合（インストールの前後に自動的に実行され、アップグレードをインテリジェントに処理します）。
  • アップストリームファイルバージョンをブランチとして扱います。
  • 事前に入力された無視リスト。
  • いくつかの基盤となるVCS（特に分散型）のサポート。

私はDebianとその派生物の下で etckeeper を使用しています。アップストリームバージョンを追跡しないことを除いて、上記のすべての機能を備えています。特に* BSDでの代替案について学びたいと思います。

configurationversion-controletc
14
Gilles 'SO- stop being evil'

Gentooでは、パッケージによって引き起こされた/ etcへの変更を管理するツール（dispatch-confと呼ばれる）は、変更を追跡するrcsをサポートしていますが、それはそれほど強力ではありません。

私は/ etcをgitでバージョン管理する傾向があります。特に、さまざまなブランチを使用することで、/ etcをさまざまなディストリビューションで可能な限り類似させ、できるだけ多くのものを1か所に保持できるためです（一部の領域では）それは明らかに失敗します。たとえば、Apacheの構成はディストリビューションによって大きく異なります）。それはこのように動作します：

masterリポジトリにデフォルトの構成ファイルがあります。今、私は新しいディストリビューションと連絡を取り、ディストリビューションの名前（この例ではdebian）に基づいてmasterブランチに基づいて新しいブランチを作成します。 Debianはいくつかの設定ファイルを私のmasterとは異なる場所に保持しているので、私はgit mv file new_loc。そして、すべてが大丈夫です。 masterに戻ってそのファイルを変更します。特定のconfigディレクティブを追加したためです。masterをdebianブランチにマージすると、移動したファイルが変更されるため、基本的にmasterブランチ内のほとんどのものを変更し、「配布」ブランチの変更をマージする必要があります（通常、配布ブランチと目的ブランチが混在する傾向があります。DebianサーバーはDebianといくつかの違いがあります。ワークステーションは明らかにですが、機能は引き続き機能します）。

つまり、基本的にはmasterに「一般的な構成」があり、（オブジェクト指向プログラミング用語で言うと）それらをブランチに継承します（ブランチは相互に継承することもできます）。

それとは別に、「cherry-pick」コミット（この場合は/ etc /への変更）に対するgitのメカニズムは、特定の構成の一部のみが必要な場合に非常に役立ちました。

今あなたのアイデアのいくつかに：

  • さらにパッケージマネージャーの統合が必要な場合は、おそらくこれにラッパースクリプトを使用します（現時点では使用していません）。
  • アップストリームバージョンをブランチとして扱うと、gitで正常に機能します。これは、（部分的に）masterにマージすることがある別のブランチです。
  • Gitの無視リストは、リポジトリ内のファイル.gitignoreであるため、カバーされています。
4
tante

私はこれにFossilを使用して、ある程度の成功を収めました。詳細については、 Fossilに関する私の投稿 を参照してください。また、変更を追跡するよりもアップグレード間を移動するためのetcupdateというツールを使用しました。ある時点でfreebsd-updateのコンパニオンツールになることを目的としていたと思います。現在のステータスはわかりませんが、RELEASE-8.*システムで動作します。

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

3
G. Cito