dispatch-conf
emerge — configuration — ebuild repository — dispatch-conf
world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles
- how to revert a change
- how backups are made
- is archive-dir still an option ? it isn't in the config file by default
dispatch-conf は Portage に含まれるユーティリティで、パッケージ更新後の設定ファイルを安全かつ便利に操作するために使用されます。パッケージ更新前後の設定移行の問題に、ユーザが手動で変更を反映する必要なく対処するための、重要なツールです。
dispatch-conf を使用することで、システム管理者は Portage によってなされた構成ファイルの変更をレビューし、更新されたパッケージの構成の構造への変更を、標準化された方法で適切に管理することができます。構成ファイルの更新が必要なときには Portage はそのことを示し、dispatch-conf は新しい構成をそのまま使用するか、変更を却下するか、選択的に変更をマージすることを提案するでしょう。dispatch-conf は、ユーザがまったく修正していない構成ファイルや、現行のバージョンと CVS 関連の記述、コメント、またはホワイトスペースの違いしかない構成ファイルについては、自動的に更新するでしょう。
dispatch-conf は変更履歴を追跡し、以前の版へのロールバックを行うことができるため、間違いは元に戻すことができます。コンフィグファイルに加えられた変更はアーカイブディレクトリに保存されます。代わりに rcs と統合させて、版管理された設定ファイル管理を行うこともできます。
dispatch-conf は、CONFIG_PROTECT 環境変数内のすべてのディレクトリの変更をチェックします。CONFIG_PROTECT_MASK 環境変数内のパスの中にあるコンフィグファイルは、保護されず自動的に上書きされます。
初回の dispatch-conf の実行の前に /etc/dispatch-conf.conf の設定を編集すべきです。/etc/dispatch-conf.conf で指定されているアーカイブディレクトリをを作成する必要があるでしょう (デフォルトでは /etc/config-archive)。
更新時の構成管理問題
構成設定の移行は、あらゆるソフトウェアアップデートに伴う一般的な問題です: バージョンの変更によって挙動が変わり、以前の設定パラメータが新しいバージョンでは効果が無くなることがあるでしょう。新しい設定オプションが追加されたり、削除されたり、意味が変更されたり、各ディレクティブの名前やフォーマットが変更されることがあるかもしれません。
ソフトウェアプロジェクトはこれを自身の方法で管理します。あるプロジェクトはロバストな構成バージョンの追跡を備えていて、自動的に構成をあるバージョンから別のバージョンへと移行できるかもしれません。またあるプロジェクトは、メジャーバージョンを跨いでいたり、ずっと古いバージョンからの更新では移行に問題があるかもしれません。以前の構成を保持しつつ更新するのに問題があったり、そもそも不可能なプロジェクトもあるかもしれません。
Unix で構成を保存するための長年の慣習として、しばしば半標準的な構文を持つ、プレーンテキストファイルを使用しています。メジャーアップデートはこれらのファイルについて、手動での移行を要求したり、既存のファイルを時代遅れなものとしてしまうことがあります。これは今日では面倒なものに思われるかもしれませんが、構成を管理し、構成ディレクティブのバージョン間の差異による曖昧性を排除するための、非常に堅牢な方法であり続けています。このことは、インターネットサーバなどの多くのサービスにとっては重要なことで、場合によっては必須ですらあることです。
設定
ファイル
dispatch-conf の設定ファイルは /etc/dispatch-conf.conf です。このファイル内で archive-dir 変数が参照するディレクトリを作成しておく必要があるかもしれません。
RCS (revision control system) との統合
RCS を使用するように設定した場合、アーカイブされたファイルの読み込みおよび実行権限は、ファイルの初回のチェックイン時から引き継がれるかもしれません。作業中のファイルの権限がそれ以降変更されても、初回のチェックインの権限はそのままかもしれません - これは思わぬセキュリティ問題を引き起こすおそれがあります。RCS ファイルへのアクセスは、親ディレクトリの権限を設定することで制御することができます。
dispatch-conf が rcs と統合するように設定されると、/etc/config-archive にすべての変更が保管されるでしょう。
revision control system をインストールしてください:
root #
emerge --ask dev-vcs/rcs
この設定プロセスは単純に、設定ファイルに以下の内容を含めるだけです:
use-rcs=yes
これで管理者は、rlog のような rcs ユーティリティを使用して差分を確認したり、co を使用して変更をロールバックしたりすることができます。rcs ユーティリティは、自身をロックするファイルを使用して動作するので、管理作業を行うのに必要なときは以下のことを理解しておいてください:
- dispatch-conf は、パッケージがファイルの置き換えを提案したときにその変更を保存するだけです。それ以降に加えられた変更は登録されません
- ファイルをチェックアウトするときに rcs はファイルシステムにファイルを書き出そうとするので、先に確実に既存のファイルをバックアップするか、標準出力を使って操作してください (後述)
- ファイルをチェックインするには、そのファイルに対するロックをまず取る必要があります。また、作業中のファイルを削除しないようにしてください
/etc/conf.d/udev に対するコミット履歴を確認するには:
user $
rlog /etc/config-archive/etc/conf.d/udev,v
RCS file: /etc/config-archive/etc/conf.d/udev,v Working file: udev head: 1.1 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: Archived config file. ---------------------------- revision 1.1 date: 2011/06/15 18:14:59; author: root; state: Exp; branches: 1.1.1; dispatch-conf update. ---------------------------- revision 1.1.1.1 date: 2011/06/15 18:14:59; author: root; state: Exp; lines: +3 -2 dispatch-conf update. =============================================================================
特定のバージョンにロールバックするための簡単な方法は、以前のバージョンをチェックアウトすることです:
root #
cp udev udev.orig
root #
co -p -r1.1.1.1 /etc/config-archive/etc/conf.d/udev,v > udev
etc/config-archive/etc/conf.d/udev,v --> standard output revision 1.1.1.
最終的な変更を加えたら (加えた変更を後でマージするために、バックアップの udev.orig を使用することもできます)、そのファイルをふたたびチェックインしてください:
root #
co -p -l /etc/config-archive/etc/conf.d/udev,v
ファイルを編集して、最後に変更をチェックインしてください:
root #
ci -l /etc/config-archive/etc/conf.d/udev,v
/etc/config-archive/etc/conf.d/udev,v <-- udev new revision: 1.2; previous revision: 1.1 enter log message, terminated with single '.' or end of file: >> Merged changes for persistant rules >> . done
diff または merge ツールを変更する
diff の出力に色を付ける
すべてが灰色のテキストで変更を読むのはちょっとうっとおしいです。幸運にも、sys-apps/diffutils の現代的なバージョンには --color
スイッチがあり、これで変更の種類ごとに異なる色を付けて表示できます。設定は単純です - 設定ファイル内の diff の行を次のように変更してください:
diff="diff --color=always -Nu '%s' '%s'"
それか、パッケージ app-misc/colordiff を使用することもできます。次で colordiff をインストールして:
root #
emerge --ask app-misc/colordiff
それを使用するように設定を変更してください:
diff="colordiff -Nu '%s' '%s'"
変更をマージするために (g)vimdiff を使う
ファイルをマージするデフォルトの方法の代わりに、vimdiff/gvimdiff を使用することができます。これを行うには、/etc/dispatch-conf.conf 設定ファイルの merge の行を変更してください:
merge="vimdiff -c'saveas %s' -c next -c'setlocal noma readonly' -c prev %s %s"
vimdiff (gvimdiff ではさらに -f
オプションを使用してください) は変更をマージするのにも使用できます。Neovim を使用する場合は、末尾の %s %s
を -d %s %s
で置き換えてください。
マージ結果として保存されるオリジナルの設定ファイルは左側のペインに保持されているので、左側のペインに変更を加えて保存してください。その助けとなるように、右側のペイン (新しい設定ファイルを含んでいます) は編集不可の読み込み専用としてマークされていることを覚えておいてください。
マージに関連して vimdiff で使えるいくつかのコマンドです:
"]c" : 次の変更にジャンプする "[c" : 前の変更にジャンプする "CTRL-W <Right>" または "CTRL-W <Left>" : もう一方のウィンドウに移動する "do" (diff obtain): ハイライトされたブロックのテキストをもう一方のウィンドウから取得する "dp" (diff put) : ハイライトされたブロックのテキストをもう一方のウィンドウに送る "zo" : カーソルの下の折り畳みを開く "zc" : カーソルの下の折り畳みを閉じる "zr" : すべての折り畳みを開く ":wqa" : 保存して終了する
さらなるヘルプについては Vim のドキュメンテーションを参照してください。
変更をマージするために imediff2 を使う
さらに別の merge の代替として dev-util/imediff2 があります。このシンプルなツールを使用すると、わずかなキー操作で選択肢を切り換えることができます。これは主に a または b キーで行われます。さらに手動でマージするために、e キーを押すことで、EDITOR シェル変数に設定されているユーザの好みのエディタを開きます。
これを dispatch-conf と併用するためには、まず imediff2 をインストールしてください:
root #
emerge --ask dev-util/imediff2
そして、/etc/dispatch-conf.conf を設定してください:
merge="imediff2 -c -N --output='%s' '%s' '%s'"
使い方
呼び出し
設定ファイルは通常 root が所有しているので、dispatch-conf は root として実行すべきです:
root #
dispatch-conf
AMD64 ハンドブックと man ページには使い方についてのさらなる情報が含まれています:
user $
man 1 dispatch-conf
ヒント
git リポジトリ内に設定の変更を記録する
etckeeper をインストールすると、dispatch-conf にフックして実行のたびに設定ファイルのバックアップを作成させることができます。
関連項目
- etc-update (AMD64 ハンドブック)
- cfg-update — a utility used on Gentoo to manage configuration file updates.