ククログ

Debianでパッケージをリリースできるようにしたい - WNPPへのバグ登録

はじめに

オープンソースのカラムストア機能付き全文検索エンジンといえば、Groongaがあります。Groongaを使うと全文検索機能付き高性能アプリケーションを開発することができます。

Groongaプロジェクトでは各種ディストリビューション*1向けに独自にパッケージを提供しています。そのため、比較的簡単にインストールできるようになっています。

ただ、パッケージをインストールするのに、あらかじめ独自に提供しているリポジトリを登録しないといけないのがちょっと面倒です。できれば、それぞれのディストリビューションの公式リポジトリからインストールできるととても楽です。

昨年の全文検索エンジンGroongaを囲む夕べ4の懇親会で、Debian開発者のやまねさんとVine Linux開発メンバーの岩井さんとお話する機会がありました。GroongaをDebianに入れたいのだけれどと相談したところ、やまねさんからわからないところはサポートしますよというありがたい一言をいただきました。そこで、現状のGroongaのパッケージについてコメントをもらうところからGroongaをDebianプロジェクトでリリースできるようにする作業ははじまりました。

今回は、現在進行中であるGroongaのDebianリポジトリ入りを目指す作業の中からバグ登録について紹介します。

Debianでパッケージをリリースするには

そもそも、Debianプロジェクトでパッケージをリリースできるようにするのに必要な手順はどんなものがあるのでしょうか。

それを簡単に説明している文書の一つに、Introduction for maintainers: How will my package get into Debianがあります。

簡単に紹介すると以下の通りです。

パッケージを決める（今回はGroonga）
WNPPにバグ登録をする
パッケージを用意する
パッケージを公開する
スポンサーを見つけ、レビューを受ける
Debianにパッケージをアップロードする
パッケージを継続してメンテナンスする

今回はこのうち、WNPPにバグ登録するところを説明します。

WNPPとは

WNPPとは、「作業が望まれるパッケージ（Work-Needing and Prospective Packages; WNPP）」を意味します。今回はGroongaが新たなパッケージ化が望まれているDebianパッケージということになります。

このWNPPに属するパッケージについてはDebian Bug report logs: Bugs in package wnpp in unstableで参照できます。

バグ登録をするには

バグ登録する場合には、定型的なメールを送信します。[groonga-dev,01967] Debianパッケージの登録作業(ITP）でやまねさんに教えてもらいました。

そこで、教えてもらった雛形を参考に以下のようなメールをsubmit@bugs.debian.org宛てに送りました。

Subject: ITP: groonga -- Fulltext search engine
From: HAYASHI Kentaro <hayashi@clear-code.com>
To: submit@bugs.debian.org
Date: Fri, 13 Dec 2013 19:05:17 +0900
X-Mailer: Sylpheed 3.4.0beta7 (GTK+ 2.24.20; x86_64-unknown-linux-gnu)

Package: wnpp
Severity: wishlist
Owner: Groonga Project <packages@groonga.org>
X-Debbugs-CC: debian-devel@lists.debian.org, debian-devel@lists.debian.or.jp

   Package name: groonga
        Version: 3.1.0
Upstream Author: Daijiro MORI <morita at razil. jp>, Tasuku SUENAGA <a at razil. jp>, Yutaro Shimamura <yu at razil. jp>, Kouhei Sutou <kou at cozmixng. org>, Kazuho Oku <kazuhooku at gmail. com>, Moriyoshi Koizumi <moriyoshi at gmail. com>
       URL: https://github.com/groonga/groonga
        License: LGPL-2.1

Description: Groonga is an open-source fulltext search engine and column store.
 It lets you write high-performance applications that requires fulltext search.

件名に入れているITPというのはなんでしょうか。これは、Intent To Packageの略語で、新たなパッケージを作成したいという宣言を意味します。その際にはX-Debbugs-CC:にdebian-devel@lists.debian.orgを指定して、Debian開発者へと周知します。

メールを送信してしばらくすると、次のようにバグが採番され、BTSへと登録できます。Groongaの場合は#732055となりました。

Debian Bug report logs - #732055 ITP: groonga -- Fulltext search engine

とても簡単ですね。

まとめ

今回はDebianでパッケージをリリースするための最初の一歩であるバグ登録について紹介しました。バグ登録をしてからも、まだまだしなければいけない作業はたくさんあります。それらについては、またの機会に記事にしたいと思います。

参考リンク

Debian JP Project 略語の解説 Debianでよく使われる略語についてはこちらを参照してください。

*1 Debian/Ubuntu/CentOSでは独自のリポジトリからインストールできるようになっています。Fedoraの場合はFedoraプロジェクト公式リポジトリからインストールできます。Fedoraだけ公式リポジトリからインストールできるようになっているのは「Fedoraプロジェクトで新規パッケージをリリースする方法」や「Fedoraプロジェクトでパッケージを更新するには」の成果です。

この記事の続き

2014-03-07

Groongaでの可変長データの管理方法

Groongaには可変長データを削除・更新しつづけるとデータベースのサイズが大きくなり続けてしまうという問題があります。次回のリリースではこの問題が解消される見込みで、現在、ユーザーにテストをお願いしています。（詳細は[groonga-dev,02173] データベース肥大化に悩むみなさんへテストのお願いを参照。）

ここでは、Groongaがどうやって可変長データを管理していて、どのようにして肥大化を抑えるようにしたかを説明します。

前提

Groongaは新しい鮮度のよい情報をすぐに検索できることを重視しています。そのため、データ更新時も検索性能を落とさないことを重視した設計になっています。具体的には参照ロックフリーという性質を実現しています。

参照ロックフリーとはデータを更新している最中でもデータを読み込める性質のことです。この性質のおかげでデータ更新中でもデータを参照できるため、検索処理がブロックしません。そのため、検索性能を落とさずに済みます。

参照ロックフリーを実現するための基本的な考えは次の通りです。

インプレースでの値の変更はアトミックに実行できる操作のみ。
- 例えば、32bit整数の変更はアトミックな操作。
アトミックに変更できない値は別の場所に新しい値を用意して、そこを指す位置だけをアトミックに変更する。
- 位置は32bit整数などアトミックに変更できる値にする。

32bit整数の値は前者の考えを使います。

32bit整数の値を変更

文字列は後者の考えを使います。

文字列の値を更新

文字列を含む可変長データはアトミックに変更できない値なので後者の方法で参照ロックフリーを実現しています。

データの更新方法の概要を説明したので、次はデータの管理方法を説明します。

データの格納方法

Groongaはデータのサイズで可変長データの格納方法を変えています。

小さなサイズのデータは固定長の領域の中に格納。
- データによっては使われない領域ができる。
大きなサイズのデータは前のデータの次の場所に連続して格納。
- 隙間なくデータを詰める。

小さなサイズのデータの格納方法を図示するとこうなります。

小さなサイズのデータの格納方法

大きなサイズのデータの格納方法を図示するとこうなります。

大きなサイズのデータの格納方法

データベースの肥大化の要因は大きなサイズのデータの格納方法にあります。

単に追加するだけの場合は大きなサイズのデータの格納方法の方が空間効率がよく、順番にデータにアクセスする場合は速いです。しかし、データの削除・更新を実行するとそのメリットが崩れていきます。

大きなサイズのデータの更新

Groongaは参照ロックフリーを実現するために、可変長データを更新するときはインプレースで書き換えません。新しい値を用意してそこへの参照を書き換え、古いデータには削除マークをつけます。

図示するとこうなります。

大きなサイズのデータの更新方法

削除する場合は単に削除マークをつけるだけなので更新の特別な場合と考えることができます。よって、ここでは更新操作についてのみ説明します。

更新操作をするたびに削除マークがついた未使用の領域が増えます。未使用の領域が増えると空間効率が悪くなり、順番にデータにアクセする速度も遅くなります。データが連続していないからです。フラグメンテーションが起きている状態です。

削除マークをつけた領域を使わないのはもったいないので、しばらくすると再利用します。しかし、再利用する条件がシビアです。そのため、再利用はなかなか進みません。これが、データベースが肥大化する原因です。

大きなサイズのデータを格納する領域は一定のサイズごとに塊になっています。具体的には4MiBごとの塊になっています。たとえば、合計12MiBのデータを利用する場合は、きっちり隙間なく詰められたとすると3つの塊が必要だということです。

削除マークがついた領域を削除する条件はこの4MiBの塊全部の領域に削除マークがついた場合です。1つでも使っている領域が残っていればその塊の中の削除マークつきの領域は再利用されません。すべて削除マークがついてようやく再利用対象になります。

図示するとこうなります。

大きなサイズのデータの再利用条件

つまり、1つでもずっと更新されないレコードがあると再利用されないということです。

データベースの肥大化を抑える方法

それでは、どうやってこの「大きなサイズのデータを更新しつづけるとデータベースが肥大化していく」問題を解決したかを説明します。

「小さなサイズ」と扱う範囲を広げました。

後述しますが、小さなサイズのデータの格納方法は比較的再利用されやすい方法になっています。そこで、よく使われるサイズのデータを小さなサイズのデータと扱うようにしました。

具体的には、これまでは128バイト未満のデータを小さなサイズのデータと扱っていたものを64KiB未満のデータを小さなサイズのデータと扱うようにしました。Groongaでは一番小さな文字列型のサイズが4KiBなので、そのサイズをカバーしています。また、多くのテキストデータは64KiB未満になることが多いため、多くのデータが小さなサイズのデータ扱いとなります。

小さなサイズのデータの格納方法は大きなサイズのデータの格納方法に比べて空間効率がよくないので追加のみのユースケースではこれまでよりもデータベースサイズが大きくなります。

Groongaは新しい情報を提供することに価値をおいているので、更新するユースケースでのメリットが非常に大きいと考えて、次のリリースからこの肥大化を抑える方法を有効にする予定です。

小さなサイズのデータの更新

それでは、小さいサイズのデータの更新方法を説明して終わりにします。

小さいサイズのデータも、新しい値を作ってからその参照を書き換えて古い値に削除マークをつける、という更新方法は同じです。そのため、それについての説明は省略します*1。削除マークがついた領域の再利用条件についてだけ説明します。

小さいサイズのデータも4MiBごとの塊の中にデータを格納しているのは同じです。塊の中で10個以上削除マークがついた領域ができると削除マークがついた領域を再利用します。大きなサイズのデータよりもだいぶ緩い条件です。

図示するとこうなります。

小さなサイズのデータの再利用条件

レコードが10件更新されるだけで再利用条件を満たすので、再利用頻度がだいぶあがります。再利用が増えるのでデータベースの肥大化を抑制できるというわけです。

まとめ

Groongaには可変長データを更新しつづけるとデータベースが肥大化するという問題があった。
次回のリリースからその問題が解消する。
64KiB未満のデータを再利用しやすい格納方法に変更することで解消。
解消方法をテストしてくれる人を募集している。
- 詳細：[groonga-dev,02173] データベース肥大化に悩むみなさんへテストのお願い

*1 データのサイズごとに固定長の領域のサイズを変えて隙間をできるだけ小さくしようとしているということは説明したほうがよいのですが、省略します。

この記事の続き

2015-01-07: 2015年にやりたいことと2014年のまとめ

2014-03-13

test-unitならRSpec 3のComposable Matchers相当のことをどう書くか

RSpec 3の新機能であるComposable Matchersの使い方の例をtest-unitならどう書くか紹介します。リンク先のコードを示し、それのtest-unitバージョンを示す、という流れを繰り返します。

テスト対象

テスト対象は次のコードです。

class BackgroundWorker
  attr_reader :queue

  def initialize
    @queue = []
  end

  def enqueue(job_data)
    queue << job_data.merge(:enqueued_at => Time.now)
  end
end

キューの中身をチェック

RSpec 3ではComposable Matchersを使ってこう書くそうです。（リンク先から引用。以下同様。）

describe BackgroundWorker do
  it 'puts enqueued jobs onto the queue in order' do
    worker = BackgroundWorker.new
    worker.enqueue(:klass => "Class1", :id => 37)
    worker.enqueue(:klass => "Class2", :id => 42)

    expect(worker.queue).to match [
      a_hash_including(:klass => "Class1", :id => 37),
      a_hash_including(:klass => "Class2", :id => 42)
    ]
  end
end

test-unitではこう書きます。RSpecは「フレームワーク側が」必要な値だけ比較するという方針ですが、test-unitは「テストを書く側が」必要な値だけ取り出して比較するという方針です。

class BackgroundWorkerTest < Test::Unit::TestCase
  class EnqueueTest < self
    def test_order
      worker = BackgroundWorker.new
      worker.enqueue(:klass => "Class1", :id => 37)
      worker.enqueue(:klass => "Class2", :id => 42)

      assert_equal([
                     {:klass => "Class1", :id => 37},
                     {:klass => "Class2", :id => 42}
                   ],
                   normalize_queue(worker.queue))
    end

    private
    def normalize_queue(queue)
      queue.collect do |job_data|
        {
          :klass => job_data[:klass],
          :id    => job_data[:id],
        }
      end
    end
  end
end

リンク先ではテスト結果の失敗時にどのように報告するかについても触れています。enqueueの実装がコメントアウトされていたときを例にしています。

class BackgroundWorker
  # ...
  def enqueue(job_data)
    # queue << job_data.merge(:enqueued_at => Time.now)
  end
end

RSpec 3の場合は次のようになって読みやすい、ということです。英語で読みくだせるのがポイントですね。

1) BackgroundWorker puts enqueued jobs onto the queue in order
   Failure/Error: expect(worker.queue).to match [
     expected [] to match [(a hash including {:klass => "Class1", :id => 37}), (a hash including {:klass => "Class2", :id => 42})]
     Diff:
     @@ -1,3 +1,2 @@
     -[(a hash including {:klass => "Class1", :id => 37}),
     - (a hash including {:klass => "Class2", :id => 42})]
     +[]

   # ./spec/background_worker_spec.rb:19:in `block (2 levels) in <top (required)>'

test-unitの場合は次のようになります。RSpecとは対照的に、英語を極力排除して実際のプログラムとデータを見せる方に注力しています。

Failure:
test_order(BackgroundWorkerTest::EnqueueTest)
test-worker.rb:22:in `test_order'
     19:       worker.enqueue(:klass => "Class1", :id => 37)
     20:       worker.enqueue(:klass => "Class2", :id => 42)
     21: 
  => 22:       assert_equal([
     23:                      {:klass => "Class1", :id => 37},
     24:                      {:klass => "Class2", :id => 42}
     25:                    ],
<[{:id=>37, :klass=>"Class1"}, {:id=>42, :klass=>"Class2"}]> expected but was
<[]>

diff:
? [{:id=>37, :klass=>"Class1"}, {:id=>42, :klass=>"Class2"}]

Compound Matcher Expressions

Compound Matcher Expressionsという機能は次のように書ける機能ということです。これまではstart_withのチェックとend_withのチェックを別に書かなれければいけなかったのに、一緒に書けるようになったということです。

1	expect(alphabet).to start_with("a").and end_with("z")

test-unitではこう書きます。期待するパターンなら特定の文字列に置換します。一回で比較するという方針は同じです。

1
2
3

alphabet = "abcxyz"
a_z = "a...z"
assert_equal(a_z, alphabet.gsub(/\Aa.*z\z/, a_z))

次のように期待したパターンでない場合は元の文字列が変わらないので失敗します。

1
2
3

alphabet = "abcxyZ"
a_z = "a...z"
assert_equal(a_z, alphabet.gsub(/\Aa.*z\z/, a_z))

失敗時のメッセージにはちゃんと元の文字列がでるので、実際の値はなんだったのか、という情報が失われることはありません。

Failure:
test_a_z(AlphabetTest)
test-alphabet.rb:7:in `test_a_z'
     4:   def test_a_z
     5:     alphabet = "abcxyZ"
     6:     a_z = "a...z"
  => 7:     assert_equal(a_z, alphabet.gsub(/\Aa.*z\z/, a_z))
     8:   end
     9: end
<"a...z"> expected but was
<"abcxyZ">

diff:
? a...z 
?  bcxyZ

まとめ

RSpec 3の例はもっとたくさんありますが、2個だけ紹介しました。

値の比較の仕方に方針の違いがでていました。

RSpecは「フレームワーク側が」必要な値だけ比較するという方針
test-unitは「テストを書く側が」必要な値だけ取り出して比較するという方針
- 参考：デバッグしやすいHTMLのテストの書き方の「おまけ: assert_match問題」のところ。

RSpec 3はより英語らしく読み書きできるようになりそうですね。

test-unitはあいかわらずRubyらしく読み書きできるテスティングフレームワークですね。

この記事の続き

2015-01-07: 2015年にやりたいことと2014年のまとめ

2014-03-19

Firefox・Thunderbirdの組織内向けカスタマイズの方法の簡単な紹介と比較

企業や団体などにおいて、組織内標準のWebブラウザとしてFirefoxの導入を検討されているお客様や、Firefoxを既に導入済みであるというお客様から、「Firefoxの設定を管理者が一括して管理したい（ユーザに管理させたくない）」という要望をよく伺います。

FirefoxとThunderbirdでは、設定を含むカスタマイズの内容を管理者の手で管理する方法にはいくつかの選択肢があり、それぞれメリットとデメリットがあります。できることの幅が狭い物から広い物へと順番に並べたものが次のリストです。

user.js
MCDのローカル設定ファイル
MCDのリモート設定ファイル
Active Directoryのグループポリシー
CCK2 Wizard
それ以外のアドオン

以下、それぞれについてどのようなメリットとデメリットがあるのか、どのような目的・場合に対して適切な選択肢となるのかを簡単に紹介します。自力での運用を検討されている方は、カスタマイズ手法の選定の参考にしてみて下さい。

1. user.js

FirefoxやThunderbirdは、プリファレンスという仕組みによって多くの設定を管理しています。user.jsは、プリファレンスに基づく設定について「固定の設定」「複数ユーザで共通の設定」らしき挙動を実現する最も手軽な手段です。詳細はabout:config と user.js による Firefox のカスタマイズ - えむもじらなどの記事を参照して下さい。

利用手順

指定したい設定の名前と値を調べる。（法人向けFAQの記述などが参考になる）
user_pref("設定名", 値); の形で設定名と値のペアを列挙したファイル「user.js」を作成する。ファイル形式は、文字エンコーディングがUTF-8のプレーンテキストとする。
user.jsをFirefox（またはThunderbird）のユーザプロファイルフォルダに設置する。
Firefox（またはThunderbird）を再起動する。

複数ユーザや他のコンピュータに設定を展開する際は、作成済みのuser.jsをコピーして3から4の手順を繰り返すことになります。

プロファイルフォルダの位置はFirefoxから辿ることができます。about:supportを開き、「プロファイルフォルダ」欄の「フォルダを開く」ボタンを押すと、現在利用中のプロファイルのプロファイルフォルダが開かれます。

メリット

導入が簡単である。（利用にあたっては管理者権限すら不要）
ユーザが設定値を万が一変更した場合でも、Firefox・Thunderbirdを再起動すると設定値が元に戻る。

デメリット

設定の仕方が独特なので、Active Directoryのような他の集中管理の仕組みとは別に運用する必要がある。
設定したい項目の設定名と適切な設定値を別途調べなくてはならない。
各PCの各ユーザーアカウントに対してファイルを設置する必要があるため、インストール対象が増えると手間が大きく増大する。（よって、2桁以上の台数のPCに展開するのは現実的でないと考えられる。）
設定を管理者が変更するためには、user.jsを全クライアントに対して設置し直さなくてはならない。
Firefox・Thunderbirdを起動している間は、ユーザが設定値を任意に変更・上書きできる。そのため、ユーザによる設定の変更を禁止しきれない。
プリファレンス以外の仕組みで管理されている設定を変更できない。例えば、以下の設定はプリファレンスで管理されていないため、この方法では変更できない。
- 有効なアドオンの一覧
- ヘルパーアプリケーションの関連付け
- Cookieやオフラインキャッシュなど、Webサイトごとに保存される情報
- 履歴
- ブックマーク
- メールフォルダの要約情報
- グローバル検索のための索引（Thunderbird）
- SSLなどの自己署名証明書や独自ルート証明書の登録

適切な用途

基本的には、個人利用向けの機能。一人で複数台のPCを利用していて、それぞれの間で共通の設定を用いるというような場合に使う。（ただ、その用途であれば現在は、Firefox Syncを使用した方がブックマークや履歴などもクライアント間で共有できて利便性は高い。）
ある程度以上の規模の組織内で広く設定を展開するのには適していない。 10人未満程度の極めて小規模の、互いが互いを信頼できるような状況で、ネットワークの初期設定を手動で行う手間を軽減するといった程度の用途に限定して使うとよいと思われる。

2. MCDのローカル設定ファイル

MCD（Mission Control Desktop）は、Netscape由来の集中管理機構です。詳細はMozilla 製品の集中管理 - 基本編 - MCDなどを参照して下さい。

元々は、設定ファイルを自動生成する管理ツールとのセットで運用する事を前提とした仕組みでしたが、Netscapeが消滅した現在では、設定ファイルの自動生成用の管理ツールがなくなってしまっています。それでも、設定ファイルを自力で作成しさえすれば、この仕組みは今でも利用できます。

利用手順

指定したい設定の名前と値を調べる。（法人向けFAQの記述などが参考になる）
defaultPref("設定名", 値); または lockPref("設定名", 値); の形で設定名と値のペアを列挙したファイル「autoconfig.cfg」を作成する。ファイル形式は、文字エンコーディングがUTF-8のプレーンテキストとする。また、ファイルの1行目は必ずコメント行とする（読み込み時に1行目だけは無視されるため）。

以下の内容のプレーンテキストファイル autoconfig.js を作成する。

1
2
3

pref("general.config.filename", "autoconfig.cfg");
pref("general.config.vendor", "autoconfig");
pref("general.config.obscure_value", 0);

作成した autoconfig.cfg を、FirefoxまたはThunderbirdのインストール先ディレクトリに置く。（Windowsであれば、 C:\Program Files (x86)\Mozilla Firefox\autoconfig.cfg などの位置）
作成した autoconfig.js を、Firefoxのインストール先の defaults/prefs/ ディレクトリに置く。（Windowsであれば、 C:\Program Files (x86)\Mozilla Firefox\defaults\prefs\autoconfig.js などの位置）

設定は、そのコンピュータでFirefox（またはThunderbird）を使うユーザすべてに影響します。他のコンピュータに設定を展開する際は、作成済みのautoconfig.jsとautoconfig.cfgをコピーして4から5の手順を繰り返すことになります。

メリット

そのコンピュータ上でFirefox（またはThunderbird）を使うユーザすべてに共通の設定を行える。
autoconfig.cfgの中ではforループやfunctionなどのJavaScriptの機能が使えるため、似たような設定を大量に施したい場合に労力やミスを減らすことができる。
プラットフォームの環境変数の値や、Thunderbirdの場合はLDAP経由でディレクトリサーバの情報を読み出せるので、if文と組み合わせるなどして、設定をある程度自動的に振り分けられる。
lockPref()を使うことで、ユーザによる設定の変更を禁止できる。

デメリット

設定の仕方が独特なので、Active Directoryのような他の集中管理の仕組みとは別に運用する必要がある。
設定したい項目の設定名と適切な設定値を別途調べなくてはならない。
設定ファイルを管理者権限で設置しなくてはならない。
各PCにファイルを設置する必要があるため、インストール対象が増えると手間が大きく増大する。
設定を管理者が変更するためには、autoconfig.cfgを全クライアントに対して設置し直さなくてはならない。
プリファレンス以外の仕組みで管理されている設定を変更できない。

適切な用途

user.jsと同様に、設定を変更する際は設定ファイルを各クライアントに設置し直さなくてはならないため、ある程度以上の規模の組織内で広く設定を展開するのには適していない。 10人未満程度の極めて小規模の組織で使うとよいと思われる。
ユーザによる設定の変更を禁止することができるため、全権を委任してしまうといったことまではできないメンバー（アルバイトなど）を含む組織では、user.jsよりも有用な場面がある。

3. MCDのリモート設定ファイル

MCDでは、autoconfig.cfg相当の内容のファイルをWebサーバやファイル共有サーバなどに設置しておき、それを毎回起動時に動的に読み込むという事ができます。これにより、設定の本格的な集中管理が可能となります。

利用手順

autoconfig.cfgと同様の内容で、リモート設置用の設定ファイル autoconfig.jsc を作成する。（autoconfig.cfgをそのまま使用してもよい）
autoconfig.jscを、パスワードの入力などの認証なしにアクセス可能なWebサーバまたはファイル共有サーバ上に設置する。
2で設置したファイルのURLを控える。ファイル共有サーバの場合は「file://」から始まるURLである。
ローカル設置用の autoconifg.js と autoconfig.cfg を作成する。 autoconfig.cfg は以下の内容で作成する。
1 2
// 1行目は必ずコメントとしてください。 lockPref("autoadmin.global_config_url", "3で控えたURL");
作成した autoconfig.js と autoconfig.cfg を、通常通りにローカルに設置する。

autoadmin.global_config_urlで指定されたURLから設定ファイルをダウンロードできなかった場合、過去に正常にダウンロードできたことがあればその時のキャッシュが読み込まれます。キャッシュがない場合はエラーとなって、FirefoxおよびThunderbirdを起動できません。

メリット

全クライアントに共通の設定を変更する際に、いちいち各クライアント上で作業を行わなくてもよい。管理者が1つの設定ファイルを編集するだけで、全クライアントに変更が自動的に反映される、という運用が可能になる。
それ以外にも、MCDのローカル設定ファイルを使う場合と同じメリットがある。

デメリット

設定の仕方が独特なので、Active Directoryのような他の集中管理の仕組みとは別に運用する必要がある。
設定したい項目の設定名と適切な設定値を別途調べなくてはならない。
導入時の最初の1回だけは、設定ファイルを管理者権限で設置しなくてはならない。
少なくとも最初の1回の起動時については、クライアントがネットワークに接続されている必要がある。
プリファレンス以外の仕組みで管理されている設定を変更できない。

適切な用途

最初の1回の設定ファイルの設置以後は、重要な設定は各クライアントに置いておかなくてもよく、それ以後は設定の変更を管理者側だけで行える。そのため、設定の変更が度々発生するような場合に特に有用である。
数百クライアント、数千クライアントといった大きな規模でも運用できる。
ユーザによる設定の変更を禁止することができるため、全権を委任してしまうといったことまではできない信頼できないメンバーを含む組織でも有用である。
外部設定ファイルを参照するため、オフラインで使用することがある端末（ノートPCなど）は、この運用には不向きである。

4. Active Directoryのグループポリシー

Firefox本体にはActive Directoryと連携するための機能は含まれていませんが、アドオンを使うことによって、グループポリシーによる設定の集中管理が可能となります。

利用手順

Active Directoryドメインに参加している各クライアントPC上のFirefoxに、アドオンGPO For Firefoxをインストールする。（具体的なインストール方法は法人向けFAQの記述などを参考にする）
GPO For Firefoxのダウンロードページの「You can find an adm file ready to be used for your GPO at the following link.」と書かれた箇所にあるリンクから、管理用テンプレートファイル（admファイル）をダウンロードして、管理コンソールに読み込ませる。
管理コンソールを使ってFirefoxの設定を行う。

以降は、ドメインに参加したWindows PC上でFirefoxを起動する度に、グループポリシーで変更された設定が読み込まれ、自動的に反映されるようになります。

メリット

構築済みのActive Directoryドメイン上で、他のグループポリシーの設定と同じ流儀でFirefoxの設定を集中管理できる。
Locked Settings以下から、ユーザによる設定の変更を禁止したい各種の設定を行える。
Default Settings以下から、ユーザによる設定の変更を許可したい各種の設定を行える。
Firefoxの設定の内部名や値の意味について、知る必要がない。

デメリット

構築済みのActive Directoryドメインが必要である。
Firefoxのインストール、アドオン「GPO For Firefox」のインストールは別途各クライアント上で行う必要がある。
MCDの設定ファイルでは使えていたような、forやfunctionなどのJavaScriptの機能、環境変数とifを使った設定の自動振り分けなどが、グループポリシー経由での管理では行えない。（代わりに、設定の振り分けはグループポリシーの適用範囲をの制御を通じて行う。）
プリファレンス以外の仕組みで管理されている設定を変更できない。
公開されている管理用テンプレートファイルが英語の物しかない。
Firefoxのバージョンアップによってプリファレンスの設定項目の名前や値の意味などが変わった場合、管理用テンプレートファイルを更新するか、自力で修正する必要がある。
公開されている管理用テンプレートファイルで用意されていない設定項目を変更したい場合は、管理用テンプレートファイルを自力で編集する必要がある。

適切な用途

既にActive Directoryドメインを運用している場合に、特に有用である。
クライアント数が数千を超えるような大規模でも運用できる。
ユーザによる設定の変更を禁止することができるため、全権を委任してしまうといったことまではできない信頼できないメンバーを含む組織でも有用である。

5. CCK2 Wizard

CCK2 Wizardは、Firefoxのカスタマイズ用のファイルを作成するためのウィザードを提供するアドオンです。このウィザードに従って操作を行い、作成された設定用ファイルを各クライアントにインストールすることで、様々なカスタマイズ内容を一度に反映することができます。

利用手順

管理者のPC上のFirefoxに、CCK2 Wizardをインストールする。
ツールバー上に追加される「CCK2 Wizard」ボタンをクリックし、ウィザードを起動する。
「File」→「New」と辿り、カスタマイズ用設定の名前と一意な識別子を入力する。
ウィザード（設定の入力画面）が出るので、行いたいカスタマイズの内容を決定する。
ウィザードの最後のページで「Create an Extension」または「Use AutoConfig」ボタンを押下し、カスタマイズ用のファイルを出力する。
- 「Create an Extension」を選択した場合、アドオンのインストールパッケージが出力されるので、各クライアントにアドオンをインストールする。（ユーザ権限ではなく管理者権限でインストールする場合は、具体的なインストール方法は法人向けFAQの記述などを参考にする）
- 「AutoConfig」を選択した場合、カスタマイズ用ファイルを圧縮したZIPファイルが出力されるので、各クライアントのFirefoxのインストール先にZIPファイルの内容を展開して設定ファイル群をインストールする。

メリット

ユーザによる設定の変更を禁止したい設定と、ユーザによる設定の変更を許可したい設定を行える。
Firefoxの設定の内部名や値の意味について、知る必要がない。
プリファレンスでは行えないカスタマイズも行える。具体的には以下のことが行える。
- 他のアドオンのバンドル。
- プラグインのDLLファイルのバンドル。
- 検索プロバイダ（検索エンジン）の定義ファイルのバンドル。
- ブックマークの内容の初期設定の変更。
- Windowsのレジストリの値の変更。
- 独自の証明書の自動インポート。
- about:configへのアクセスの禁止。
カスタマイズ用設定のプロジェクトを複数保存しておき、カスタマイズ用ファイルを作り分けることができる。
アドオンの自動アップデートという形で、カスタマイズ内容の更新をクライアントに自動配信し、設定を集中管理することができる。

デメリット

設定の仕方が独特なので、Active Directoryのような他の集中管理の仕組みとは別に運用する必要がある。
ウィザードが英語の物しかない。
CCK2 Wizard自体が対応している設定項目以外の設定には、MCDの設定ファイルを手描きするのと同じ程度の手間と知識が必要。
CCK2 Wizard自体が対応しているカスタマイズ項目以外のカスタマイズは難しい。
カスタマイズ内容の更新をクライアントに自動配信して集中管理するためには、アドオンのアップデート情報を独自に提供する必要がある。

適切な用途

アドオン形式で独自にアドオンのアップデート情報まで含めて提供するのであれば、数千クライアント以上の規模にも対応できると思われる。
その場合、最初の1回の設置以後は、重要な設定は各クライアントに置いておかなくてもよいため、設定の変更が度々発生するような場合に特に有用である。
ユーザによる設定の変更を禁止することができるため、全権を委任してしまうといったことまではできない信頼できないメンバーを含む組織でも有用である。
カスタマイズ用のアドオンの数をあまり増やしたくない人にも有用である。

6. それ以外のアドオン

ここまでで挙げた中ではCCK2 Wizardが最も柔軟性の高いカスタマイズ手段となりますが、CCK2 Wizardでもできないようなカスタマイズを行いたい場合には、現実的にはやはり、「そのためのアドオンを使用する」ということになります。例えば、以下のような例があります。

Thunderbirdの新規メールアカウント作成用ウィザードをカスタマイズしたい場合→AutoConfiguration Hookを利用する。
メジャーアップデートの適用を禁止してセキュリティアップデートの適用だけを許可するという運用をしたい場合→Only Minor Updateを利用する。

法人向けFAQでも、組織内での運用で便利と思われるアドオンをいくつか紹介しています。また、既存のアドオンでニーズを満たせない場合は、独自にアドオンを開発するという選択肢もあります。

アドオンを全ユーザ向けに管理者権限でインストールする方法も、目的に応じていくつかの選択肢があります。法人向けFAQに詳しい記述がありますので、そちらも併せて参照して下さい。

まとめ

以上、FirefoxやThunderbirdを組織内で利用するにあたって管理者の手でカスタマイズ内容を管理するいくつかの選択肢を比較する形で紹介しました。

この記事では、それぞれのカスタマイズ手法のメリットとデメリットという所に焦点を当てて紹介しましたが、そもそもどんな点をカスタマイズできるのか？という事自体に関心があるという方もいらっしゃることでしょう。上記文中でも紹介していますが、組織内での利用で行いたくなりがちな様々なカスタマイズについて、現在Mozilla Japanと共同でFAQの編纂を進めています。概要を把握するためにも、まずはFAQをざっと眺めてみて下さい。

また、クリアコードでは、FirefoxおよびThunderbirdの利用にあたってお困りのお客様について、問題を解決するお手伝いをしています。FirefoxやThunderbirdの導入やカスタマイズでお困りで、自力での解決が難しいという場合には、弊社有償サポート窓口までぜひ一度ご相談下さい。

ところで、4月9日に行われるIE6はEOLだが、これからのWeb系システムは本当にブラウザでいいのか？ - エンタープライズWebプラットフォーム大戦争というイベントで、Firefoxの企業での利用について弊社の結城が発表させていただくことになりました。イベントのタイトルからは少し離れた話題となりますが、上記の話も含めて、FirefoxやThunderbirdの企業利用のカスタマイズ事例について紹介させていただく予定です。定員は既に満席のようですが、直前になるとキャンセルが出ることが予想されますので、このような話題に関心があるという方は、諦めず補欠登録しておいてみてはいかがでしょうか？