今までSamba日本語版での問題点は、バージョンアップでコードに変更が加わったとき、その変更部分が他の機能に与える影響、つまりリグレッションの確認でした。コードの一部分が変わってしまったため、それまで動いていた機能が動かなくなるなど、その確認にかかる負担もSambaの機能拡大に伴って増えていきました。

Samba 3.0からは全ての文字コード変換はiconvで行われるようになったため、オリジナルのSamba 3.0さえ正確に文字コード変換を行っていればどの言語でも動くようになりました。

ところが、Sambaの開発者の大部分は日本語を含むマルチバイト文字の環境を持っていません。これが意味するところは、そういった環境を持たない開発者にとって国際化のバグ修正は、まず第一にバグ自体が発見できない、また発見されても直し方がわからない、最後に直してもテストする方法がない、という非常に労力を伴う作業になります。

もし国際化を確認するための自動テストを作ることができれば、検証に必要な環境を持ち合わせていない人に対しても、まずバグの存在をわかりやすい形で訴えることができます。また、テストに通ることがバグ修正につながるので、コード修正の確認も容易に行えます。

また、一旦自動テストがSamba開発の枠組みに組み込まれれば、将来的にリリースされるコードもこのテストを通っていることとなり、今後のリリースでは最低限の自動テストを通ったという品質が保証されることになります。

Sambaのソースコードを展開すると、"testsuite" というディレクトリがあり、 その下にはテストスクリプトが格納された複数のディレクトリが存在します。 ただ、"testsuite/build_farm" 以外のディレクトリは未公開バージョンの DejaGNU を必要とし、これらのテストを行うことは現実的ではありません。

【リスト1】Sambaのソースコードの構造
    Samba-3.0.0/COPYING
               /Manifest
               /README
               /Read-Manifest-Now
               /Roadmap
               /WHATSNEW.txt
               /docs/
               /examples/
               /packaging/
               /pcp/
               /source/
               /swat/
               /testsuite/README
                         /build_farm/  <== テストが格納されているディレクトリ
                         /config/
                          :

このドキュメントでは、"testsuite/build_farm" に格納されたテストを実行する 方法を解説します。これらのテストは単体では動作せず、samba.org の CVS から取得できる build_test によって構築されたテスト環境で実行する必要があります。

ビルドファームとは自動テスト実行環境であり、CVSに登録されている最新のSambaのソースコードに対して、毎日自動テストを実行しています。 ビルドファームではCVSからのソースコード取得に始まり、configure、build、install、test という一連の動作をチェックします。

当プロジェクトではこの自動テスト環境とSambaのテストプログラムに国際化の対応度をチェックするためテストを追加するのパッチを作成しました。

このテストを実行するにあたり、以下の条件が満たされている必要があります。

• bash が導入されている
• CP932 と EUCJP-MS が組み込まれている glibc か libiconv が導入されている
• perl とその基本的なモジュールが導入されている
• autoconf のバージョン 2.53 以降が導入されている
• sudo が導入されている
• 実行ユーザは root か sudo の権限を持っている
• 余裕を持ったディスクスペース (ギガ単位)

glibc と libiconv については、パッチについての詳しい情報が iconvについて にて公開されていますので、 参照してください。

以上の条件が満たされているの確認し、ビルドファームを構築します。

まず、samba-3.0.2a-testsets.tar.gz をダウンロードし、glibc が導入されて いる場合には build_farm_glibc.patch、libiconv が導入されている場合は build_farm_libiconv.patch をダウンロードしてください。

次に、パッチをあてるオリジナルのビルドファーム作成スクリプト郡を、 samba.org の CVS から入手します。プロジェクト名は "build_farm" です。 ファイルを入手するには、カレントディレクトリにて下記のコマンドを 実行してください。

    $ cvs -d :pserver:cvs@pserver.samba.org:/cvsroot login
    Password: cvs
    $ cvs -z5 -d :pserver:cvs@pserver.samba.org:/cvsroot co build_farm

以上のコマンドを入力すると、カレントディレクトリに build_farm ディレクトリが 作成され、ビルドファームを構築するのに必要なファイルが展開されます。 デフォルトのままだと、build.samba.org のマスターサーバと交信を自動的に 行ってしまいます。そこで先ほどダウンロードしたパッチをあて、 スタンド・アローンのビルドファームとして構築します。

ダウンロードしたパッチを、オリジナルのビルドファームに適用するには、 以下のコマンドを実行してください。

    $ patch -p0 < build_farm_glibc.patch (build_farm_libiconv.patch)

また、テスト前に build_farm ディレクトリ直下に samba のソースコードを 展開、パッチを当てます。ディレクトリの名前は samba と指定します。

    $ tar -jxvf samba-3.0.2a.tar.bz2
    $ tar -zxvf samba-3.0.2a-testsets.tar.gz
    $ patch -p0 < samba-3.0.2a-testsets.patch
    $ mv samba-3.0.2a ./build_farm/samba

一度の複数のテストを同時に実行するときはエラーログが大変大きくなる恐れが あります。samba/testsuite/build_farm/runlist というファイルの中に $TEST_ALL という環境変数が設定されているので、この変数の値を調整することを お勧めします。 特に初めてテストを実行する場合、大量のエラーログを吐いてしまう可能性が あるので注意してください。

./samba/testsuite/build_farm/runlist
    TEST_ALL="TORTURE-I18N_FILE_CREATE"
    
    #TORTURE-I18N_FILE_CREATE_match (# などでコメントアウト)

以上の準備ができたら、build_test スクリプトを実行します。

    $ cd build_farm
    $ ./build_test

テストが終了したら ./build_farm ディレクトリに作成されたログファイルやエラーファイルを参照し、テストが思惑通り実行できたか、テストが全て成功したかの確認を行ってください。

	ログファイル	build.<プロジェクト名>.<マシン名>.<コンパイラ名>.log
	エラーファイル	build.<プロジェクト名>.<マシン名>.<コンパイラ名>.err

テストに使用したデータに関しては、こちらの 「テストに使用したデータ」 を参照してください。

smbclient などのSMBクライアントがサーバに接続する際、$LIBSMB_PROG 変数が設定されていると、クライアントは cli_connect() 関数実行時に通常の接続ではなく、smbd をフォークプロセスとして起動させ、標準の入出力をこの接続につなげます。

下のコードを参照すると、環境変数が設定されていると sock_exec() 関数を呼んでいることがわかります。

sock_exec() 関数はfork()して新しいプロセスを起動し、親と子供の入出力をパイプでつなげます。他のプロセスからはこのソケットには接続できません。

【ソース2】./build_farm/samba/source/lib/sock_exec.c
    int sock_exec(const char *prog)
    {
        int fd[2];
        if (socketpair_tcp(fd) != 0) {
                DEBUG(0,("socketpair_tcp failed (%s)\n", strerror(errno)));
                return -1;
        }
        if (fork() == 0) {
                close(fd[0]);
                close(0);
                close(1);
                dup(fd[1]);
                dup(fd[1]);
                exit(system(prog));
        }
        close(fd[1]);
        return fd[0];
    }

ビルドファームの環境では $LIBSMB_PROG が定義されているので、SMBクライアントがサーバに接続しようとするたびにテスト環境でビルドした smbd に対して起動、接続することになります。

CVS で取得した build_farm ディレクトリの中の build_test.fns には、テスト実行時には常に $LIBSMB_PROG が指定されています。

【ソース3】./build_farm/build_test.fns
    action_test_samba() {
             :
        LIBSMB_PROG=$prefix/sbin/smbd
        export LIBSMB_PROG
             :
    }

もし外部のWindowsサーバを参照するテストを作成したい場合は、この環境変数をリセットし、適切な smb.conf の設定を行ってからテストを実行してください。

なお、ビルドファームでビルドした smbd が参照する smb.conf のデフォルトの格納先は "$prefix/lib/smb.conf" です。

【ソース4】任意のテスト 例:) ./build_farm/samba/testsuite/build_farm/basictest.test
    test_dummy() {

	_LIBSMB_PROG_BACKUP="$LIBSMB_PROG"
	unset LIBSMB_PROG
	
	<_テスト_実行_>
	
	LIBSMB_PROG="$_LIBSMB_PROG_BACKUP"
	export LIBSMB_PROG

    }
    
    test_dummy

これで、ビルドファームでビルドしたクライアントでも外部サーバを参照することができます。