Samba の過去・現在、そして未来

1999年12月18日(土)、パシフィコ横浜にて開催された Linux Conference '99 において、Samba Term の Jeremy Allison 氏と日本 Samba ユーザ会および有志の方々との会合が開かれました。 その中で、Jeremy 氏は Samba の過去・現在、そして将来の姿 (構想) を語ってくださいました。 以下はそのときに紹介された機能や図などをまとめたものです。

前日のロビーで展開された議論と、会合後の昼食での話も含まれています。 ご了承ください。

目次

• 歴史
• CVS ツリー
• 次期バージョン (2.0/2.2/3.0)
• 内部文字コード
• smb.conf の文字コード
• 各種テーブルの db 対応
• 独自仕様の WINS 複製実装
• 独自仕様の BDC 実装
• VFS (Virtual File System)
• winbind デーモン
• カーネルの oplock サポート
• パフォーマンス
• そのほか
• 開発者・貢献者を募集!

歴史

簡単に Samba の歴史について触れられました。 Jeremy 氏の記憶違いがあったため、適宜修正してあります。 また、あまり厳密に調べていないので間違いが残されている可能性があります。 ご了承下さい。

Server 0.1 (1991年)

Andrew 氏による Samba の最初の姿

• 非常に小さな開発

Server 0.5 (1992年)

各種プロトコル仕様の実装

• CORE (by Andrew?)
• CORE+ (by Jeremy)

Samba 1.6.x 〜 1.8.05 〜 1.9.15p8 (1994 〜 1995年)

各種プロトコル仕様の実装

「LANMAN 1.0 by Andrew は ``good vintage'' だ」とは Jeremy 氏の言葉です。

• LANMAN 1.0 (by Andrew)
• LANMAN 2.0 (by Jeremy)
• 日本語ファイル名のサポート (1.8.xx のころらしい)
• LFN (Long File Name) サポート

Samba 1.9.16 (1996年)

1 年ほど続いたバージョン

このころ、Andrew 氏も Jeremy 氏も多忙だったとのこと。

Jeremy 氏は Whistle Communications に在籍。

同社はサーバ製品に Samba を採用し、メンテナンスを行っていた。

• マスター・ブラウザ
• ドメイン・ログオン (Windows NT クライアント以外)

Samba 1.9.17 (1997年)

このころから Samba の I18N を真剣に考えるようになったそうです。

• 暗号化パスワード認証サポート (以前からあるので、「正式」ということ?)
• client code page パラメータを導入

Samba 1.9.18 (1998年)

• oplock サポート
• nmbd を書きなおし
• client code page の定義ファイルが書けるようになった

Samba 2.0.x (1998年 〜)

NT 仕様の実装

• NTLM 0.12 の本格的実装 (一部は以前からあり)
• DCE/RPC over SMB (by Luke?)
• ACL の UNIX <-> NT マッピング
• prelinary(?) PDC

CVS ツリー

Samba のソースコードは CVS によって維持されています。 開発は目的ごとに「ブランチ」に分離され行われています。

HEAD ブランチ

次期の安定バージョンである「Samba 3.0」を開発するためのブランチです。 このブランチは少し前までは「Samba 2.1-prealha」と呼ばれるバージョンでしたが、これは「SAMBA_TNG」ブランチに移動しました。 主に Andrew 氏によって、SAMBA_TNG の成果を取り込む作業が行われているとことです。

• PDC
• VFS
• spoolss
• Samba 2.0.7 以降に追加される拡張の取り込み

SAMBA_2_0 ブランチ

現在の安定バージョンである「Samba 2.0.x」のブランチです。主に Jeremy 氏によって作業が行われています。

• UNIX ACL サポート
• 内部コードの UNICODE 化
• bugs fix

SAMBA_TNG ブランチ

先進的な機能を実験的に実装するためのブランチです。主に Luke 氏によって開発が進められています。Luke 氏によるハッキングとその成果は非常にすばらしいものですが、正常パターンで「とりあえず動く」以上のことはない、つまりはコードにはエラーチェックなど施されていないそうです。よって、あるときには不安定であったり、セキュリティの問題をはらんでいると言えます。

• PDC
• LDAP, NDS
• Trusts (信頼関係)
• NTLMv2
• spoolss
• VFS
• samr (NT の SAM アクセス RPC 対応など?)

次期バージョン

Samba 2.0.7 〜

現在の安定版

• バグ修正が中心
• 機能拡張も多少はあるかもしれない

Samba 2.2

3.0 までのマイルストーン?

• NT 仕様のプリンタ機能 - spoolss (by Jeremy)
• UNIX ACL サポート (by Jeremy)
• 内部コードを UNICODE 化 (by Jeremy)
• 各種テーブル (smbpasswd など) の db 化 (by Andrew)

Samba 3.0

来年 3 月を目標?

• NT 互換 PDC 実装
• 独自仕様 BDC 実装 (未定)
• 独自仕様 WINS 複製実装 (未定)
• VFS (Virtual File System) 対応

以下は、Jeremy 氏の談です。

次期のバージョンをどうするかは、多分にマーケティング的な色彩が強い。 PDC 機能がサポートされれば確実に次期バージョンは Samba 3.0 になると思うが、そうでない場合はわからない。

内部文字コード

現在の Samba (2.0.6) は、ファイル名や NetBIOS 名などの文字列を「pstring」という型の変数に格納しており、それらの文字コードは「client code page」に指定された DOS のコードページ (以下、dos cp) に従ったコードになっています。

これら文字列をクライアントとやりとりする場合、旧来の SMB であればそのまま使い、UNICODE を要求する SMB であれば適宜 dos cp と UNICODE 間で変換を行っています。 これらの文字列を UNIX のシステムコールなどとやり取りする場合は、「character set」もしくは「coding system」(日本語対応) の設定に従って、dos cp との間で変換を行っています。

Samba 2.0.5 以前は、NetBIOS 名やコメントでは ASCII 文字しか考慮されていません。 2.0.6 でもまだ不完全で、SAMBA_2_0 ブランチの最新版にパッチをあてることで大体動作するそうです。

内部と外部の文字コードの扱い (現在)

Jeremy 氏は将来の I18N / M17N 対応のため、内部コードを UCS2 に切り換える作業を行っているとのことです。 以下の図のように、現在は UCS2 (16bit) による実装が進められています。 Jeremy 氏によると、UNICODE のバージョンに依存するような部分は「大文字・小文字の扱いくらい」とのことで、将来の改変された UNICODE スペックへの移行も問題ないだろうとのことでした。

内部と外部の文字コードの扱い (将来)

この図だと、ファイルの中身の文字コードも変換されるようにも見えるかもしれませんが、過去もこれからもそのような実装はされません。 対象はファイル名や NetBIOS 名などです。 ユーザ名、グループ名も含まれるでしょう。

smb.conf の文字コード

smb.conf の文字コードについて、Jeremy 氏に尋ねました。 (これは 17 日に出た話です)

現状 Samba で 1byte の文字(いわゆる半角カタカナ)を Unicode にマッピングするロジックがないことを指摘したのですが、内部を UCS-2 にすれば関係なくなるでしょ、とかわされてしまいました。 本当はもうすこし追求しようかとも思ったのですが、英語力のなさと、結局日本語特有の問題は、日本で解決してと言われそうなのが目に見えていたので断念しました。

「Samba の内部を Unicode にするとしても、smb.conf 自体を Unicode にはしないですよね」と聞いたら、もちろんそうだと言う話。 しかし、Samba 自体を i18n すると、共有名などに ローカル文字セットの文字や、Unicode 文字列を使おうとする可能性を考えると、どこかで smb.conf 自体の文字コードを知らないと、smb.conf の解析が出来ないというジレンマに陥るという話をしました。 結局、smb.conf の先頭行で、smb.conf 自体の文字コードを指定するしかないかなぁとのことでした。

これはいわゆる「鶏と卵」問題ですね。 なにかよい案はないものでしょうか。

各種テーブルの db 化

smbpasswd ファイルや WINS データベースを db で管理する実装が行われているそうです。 使用する実装は GNU の dbm (gdbm) でも、Berkelay DB でもなく、独自の「tdb」を使うことが先日アナウンスされました。

Subject: new database code
From: Andrew Tridgell <tridge@linuxcare.com>
Date:   Tue, 21 Dec 1999 20:57:28 +1100

I've just committed the first of the big changes in the head (Samba
3.0) branch to do with the new database code.

For those who don't remember, the database code will be replacing a
bunch of shared data structures and lock files that have been used in
Samba previously. This should greatly simplify the internal structures
in Samba and also has some external benefits.

what has been done in CVS head so far is:

  - new tdb/tdb.c database module. I've written this to be like gdbm
    but to use shared memory and allow multiple simultaneous writers
    and locking. It also includes a test suite and a database tool

  - changed the existing connection databases (what was in STATUS..LCK
    and sharename.LCK) to use a single tdb database instead

  - changd all the existing share mode and oplock code that used
    sysv,mmap or lock files to instead use a tdb database. A nice side
    effect is that the storage for this stuff now takes up much less
    space and auto-expands as needed.

  - modified smbstatus and swat to know about the new databases.

there are still several more places in Samba that will be converted to
use tdb databases, especially the WINS code. Expect some more commits
soon.

Cheers, Tridge

独自仕様の WINS 複製実装

WINS データベースの複製プロトコルは一切公開されていません。 現在の Samba には WINS 複製の実装はありません。

プロトコルをダンプしてハックすることも可能だろうと Jeremy 氏はおっしゃっていましたが、独自複製プロトコルの実装を行う計画があるそうです。

独自仕様の BDC 実装

将来の BDC 実装の計画について伺ったところ、以下のような回答を頂きました。

Microsoft Windows NT の PDC-BDC 間の複製プロトコルをハックすることは不可能ではないが、モチベーションがそれほど無い。

なぜなら、Samba で PDC が可能になれば、BDC の機能つまりデータベース複製の機能を独自実装とすることは、ミスチョイスでは無いからだ。

PDC が SAMBA なのに、なぜ BDC にNTをつかうのか。

(PDC が NT で BDC が Samba ということか? BDC が実現できるということは、機能的に PDC が実現できていることだから、それはあり得ないのではないか?)

もちろんニーズがあればやるだろうが、いまのところプランにいれていないしもっとやりたいこと/やるべきことがある。

VFS (Virtual File System)

Linux の VFS の考え方と基本的には同じです。 VFS レイヤによってファイルの I/O 先を抽象化することにより、あらゆるストレージをファイル・システムとして利用することを可能とします。

VFS は、Samba 3.0 で実装される予定だそうです。 SAMBA_TNG ブランチの Samba には実験的な実装が既に完了しています。 以下に VFS の実際の利用例を示します。

Oracle による高速データ I/O を実現する VFS モジュール

データベース・システムは、データ I/O に特化した実装を持ちます。 また、OS が用意する遅いファイル I/O システムコールを介さずに、直接(?)、独自の I/O ルーチンを用いてストレージ・デバイスにアクセスするため、非常に高速です。

共有で用いる VFS モジュールを指定 (smb.conf)

[oracle]
    vfs = ora.so
    …そのほかの共有パラメータ…

VFS を介したデータ I/O のイメージ

vfs パラメータで指定された VFS モジュールは dlopen(2) によってロードされ、共有に対するあらゆるファイル・アクセスに利用されます。 VFS モジュールには、システムコールに似た仕様と名前を持ち、データの格納先をラッピングするインタフェース関数が用意されます。

ファイル I/O のログを作成する VFS モジュール

通常のファイル I/O のほかに、ロギング (logging) を行うような VFS モジュールを作成することが可能です。 たとえば、書き込まれるデータをすべて CD-R に記録するような VFS モジュールが考えられ、政府機関などでデータ改ざん防止のために利用することが考えられるだろう、とのことでした。

そのほかの VFS モジュール

LDAP をストレージとするモジュール、課金計算を行うモジュールなど、アイデア次第。

winbind デーモン

NIS や NIS+ ようなネームサービスを提供するデーモンです。 ただし、アカウント情報のみ (passwd と group) に限られているようです。 winbind は、Windows (あるいは Samba) の SAM のアカウント情報にアクセスし、UNIX ユーザのアカウントを提供することを可能とします。 これを用いれば、UNIX 上にユーザ登録する必要がなくなるのです。

UNIX の多くは、passwd, group といったデータベースの参照先を切り換える実装を持っています。 /etc/nsswitch.conf ファイルで設定する方法が一般的のようです。 参照先の選択肢としては、files, nis, nisplus などが選択できますが、それに「winbind」を加えるという計画だということでした。 これを実現するには、標準ライブラリ (libc) の対応も必須です。

passwd, group データベースとして winbind を使う (nsswitch.conf)

passwd:         files winbind 
group:          files winbind
shadow:         files winbind

このように記述することで、たとえば getpwnam(3) 関数を呼ぶと、winbind がバインドしている SAM からユーザ情報を得ることができるでしょう。

winbind はただ SAM をアクセスするだけでなく、UNIX と Windows の違いを翻訳する役目も負うのではないかと思われます。

カーネルの oplock サポート

Linux カーネルへの oplock サポートを Linus 氏に提案したところ「やってもいいよ」と言われたそうです。 しかし、「ただ自分はコードを書きたくないから、作ってね」とも。 カーネルハッカーの皆さん、書いてみませんか?

Jeremy 氏は Solaris や HP といった商用 UNIX でのサポートについても語ってくださったようなのですが、私の英語力がたりないため、聞き取れませんでした。 申し訳ありません。

現在では SGI の IRIX (6.5.2f 以降?) だけが、カーネルで oplock をサポートしています。 Samba 2.0.x は、これに対応しています。

「oplock」とは、SMB クライアントがサーバ上のファイルをロック (oplock) することで、クライアント側でファイルへの読み書きをキャッシュすることができる機能です。

あるクライアントによって oplock 済みのファイルに対し、別のクライアントからのアクセス要求が来ると、SMB サーバは、そのクライアントのアクセスをいったんブロック (一時停止) する一方、oplock を持つクライアントには oplock を解除 (oplock break) するように要求します。 oplock break 要求を受け取ったクライアントは、必要ならキャッシュされている未書き込みのデータをフラッシュし、oplock を解除します。 oplock が解除されると、ブロックされていた別のクライアントがアクセス可能になります。

Samba はバージョン 1.9.18 から oplock をサポートし、大幅な性能向上を得ることができました。 しかし当時は、oplock の機能を持つ UNIX カーネルは存在していなかったため、Samba の oplock 機能は Samba の中に閉じていました。 つまり、Samba のクライアントが UNIX 上のファイルを oplock していたとしても、UNIX 上の別のプロセスからはそれを知ることも、アクセスをブロックされることもないのです。

このため、「UNIX 上でファイルの内容を書き換えたが、Windows から見ると書き換わっていない!」(あるいは逆) といった現象が見られます。 つまり、UNIX カーネルの oplock サポートなしでは、UNIX と Windows の両方からアクセスする場合は「oplocks = no」にするしかないのです。

パフォーマンス

18日の会合後の昼食中に Samba のパフォーマンスについて、以下のような話を頂きました。

Q.Samba のパフォーマンスが Windows NT と良い/悪いという議論があるが、
  どちらが正しいと言えるものでしょうか?

A.Samba のパフォーマンスの限界は、主に TCP スタックの性能によって
  決まる。 SGI では 64 台のクライアントと 1 台のサーバを 2Gb の
  スイッチで接続して試験を行なった結果、そういう結論に達した。

  現在、もっとも優れた TCP スタックを搭載した UNIX (like) OS は
  Solaris (SPARC 版、Intel 版とも) である。ただ Solaris は、ディスク
  アクセス性能が低い。

そのほか

Q.kanji.c 中の WIN95_COMPATIBILITY フラグはなんのためにあるのでしょうか?

A.半角と全角を区別するか? -> 今はデフォルト区別する。
  MS がそうだから。

  Samba は互換性のために MS のバグも含めて忠実に再現しないといけない。
  そうでないと、Samba の側が Windows と仕様が違うと言われてしまう。

開発者・貢献者を募集!

Samba Team そして Jeremy 氏による Samba の将来の姿を語っていただきました。 非常に野心的かつ実用的な機能が多く、新 Samba が非常に楽しみです。

しかし、これらの中には実際に作業が進行中のものもありますが、「計画あるいは構想だけ」のものもあります。 このすばらしいアイデアを実現するためにも、「どんどん開発に参加して欲しい」ということをしきりに Jeremy 氏は強調していました。

特に I18N / M17N に関しては、「日本の開発者の貢献に期待したい」ともおっしゃっていたように思います。