インタビュー：Samba共同創始者のTridgell、ピザとパケットを語る
SMB（Server Message Block）プロトコルは、ほとんどのWindowsバージョンではMicrosoftネットワーククライアントと呼ばれ、NetBIOS名とともに、Microsoftネットワーキングの土台を形成している。たとえば、[ネットワークコンピュータ]フォルダや[ネットワーク全体]フォルダでのブラウジングには、これが使われている。最近では、Linuxはもちろん、各種UnixもSMBを理解できるようになっていて、これが企業におけるLinux導入を促進する大きな力となった。このオープンソースプロジェクトは、やがて Samba と呼ばれるようになる。Samba 2.0では、LinuxマシンがWindows NTドメインの一部となるだけでなく、そこでプライマリドメインコントローラやバックアップドメインコントローラとしても動作できるようになった。
その後、Microsoft社に大きな動きがあり、Windows 2000 Serverのリリース以後、同社はネットワーキングインフラストラクチャとしてActive Directoryなるものを構築した。これは、いわば各種プロトコルのカクテルであり、SMBとNetBIOSも使っているものの、その目的は主として後方互換性を維持することに置かれている。もちろん、Sambaも停滞していたわけではない。私は、キャンベラ（オーストラリア）の自宅にいたTridgeをつかまえ、SambaとLinux、さらには国際電話についてのバーチャルチャットを試みた。
Q：Sambaは、たぶん、いまでも最も有名なピザウェアアプリケーションでしょう。いったい、Sambaチームにはどれだけのピザが来たんですか。いまでも、新しいピザが舞い込んでくるんでしょうか。
いやあ、このピザウェアっていうのは冗談から始まったことなんですが、すぐに一人歩きを始めました。もう大昔のことですね。SambaのREADMEにこんな文章を入れたんです。
ハードウェア/ソフトウェア/現金/宝石、またはピザ引換券は、Andrew宛、直接送っていただいてかまわない。とくにピザ引換券は大歓迎。
でも、実際に送ってくる人がいるとはねえ……。ピザ引換券なんてものは、当時、存在しませんでしたよ。でも、すぐに、どこかのアイデアマンがオーストラリアのピザハットに直談判して、ピザ引換券を発行させたんです。最初の引換券は、キャンベラのLinuxユーザグループの会合でありがたく使わせてもらいました。
そのあとは、いろんな人がいろんな方法でピザを送ってきました。ピザ材料の缶詰に、ピザ引換券。近所のピザ店に私用のピザ口座を開いてくれた人、ピザのGIFをメールで送ってきた人……そうそう、折り紙ピザなんてのもありました。いくつもらったか、正確なところはわかりませんが、相当な数ではあります。
いちばんすごいのは、ドイツから近所のピザ店に電話をして、クレジットカードの番号を伝えて$300分のピザを注文した人です。これは、オーストラリアじゃすごい量のピザですよ。妻と2人でやって、食べ終わるのに何か月もかかりました。当時、2人とも学生で、収入はゼロでしたからね、いや、ほんとに助かりました。
ここ2年ほどは数が激減して、もう何か月もピザ引換券にはお目にかかっていません。でも、妻はピザなんてもう見るのも嫌だって言ってますし、私も体重を落とさなくちゃならないので、これもまた好都合です。それにいまはサラリーマンで、ちゃんと給料をもらってますから、ピザがほしくなれば自分で買えますしね。
Q：SambaのWebサイトによると、Sambaチームは現在寄付を募っていますね？ 現在の活動資金はどういうところから得ているのですか。
チーム自体がさほど資金を必要としているわけではありません。経費の主なものは、チームメンバ――とくに学生ですね――が年2回の会議に出席するための旅費と、samba.orgサーバのホスティング費用くらいのものですから。
このうちホスティング費用については、幸いなことにIBM社からたいへんありがたい申し出があって、昨年10月から、同社に負担していただいています。残るは旅費です。寄付はこれに当てています。
2年前のLinuxWorld会議で、私たちは$25,000もの賞金 をいただいて、これで旅費の台所事情がたいへん楽になりました。こういう臨時収入と寄付。それ以外には、Sambaチームとしての収入がまったくありません。
寄付についてもう少し申し上げると、最大の――そして最もありがたい――寄付は、じつはお金ではなくて時間です。社員がSambaの開発・文書化・テストに携わるのを認め、勤務時間の一部をそれに割くことを認めてくれている会社が、かなりの数あります。これはプロジェクトの前進にとってとてもありがたいことです。
Q：いま、どのくらいの人がSamba開発に携わっているんですか。
それは難しい質問ですね。Sambaチームのメンバは、現在、27人です。その意味は、コードと文書に対するCVSコミット権限をもっていて、直接アクセスできる人間がそれだけいるということです。その27人全員が開発者として現に何かをしているというわけではありません。一方、何らかの方法でSambaに関係しているものの、チームメンバではない人もたくさんいます。
たぶん、昨年中に何かのコードを書いて、それがSambaに取り入れられたという人は30〜50人ほどだと思います。定期的に何かをコミットする人が10〜15人といったところでしょうか。
Q：現時点で、SMBプロトコルにはまだ驚きの要素がありますか。それとも、もう十分に文書化されて、焦点は周辺の別の問題に移っていますか。
いや、SMBについては常に新しい発見があります。私たちがやっているのは、公式文書を整えるというより、Sambaソースコードに必要な変更や追加をコミットすることで、その作業が大部分です。もちろん、そういう気になる部分が将来のSambaバージョンではちゃんとなるように、Sambaテストツール群に新しいテストを加えることも怠れません。
Q：Active Directoryについて言われていることが額面どおりなら、これはMicrosoft社の従来のネットワーキングより扱いやすそうですね。なにしろ、DNS、LDAP、Kerberosと、きちんと文書化されたプロトコルの修正バージョンからなっているわけですから。SambaをActive Directoryと整合させるうえでの問題点は何だったでしょうか。SambaはActive Directoryドメインサーバとして使用できますか。
おっしゃるとおり、以前のNT4ドメインインフラストラクチャに比べると、Active Directoryの設計はすぐれています。しかし、まだまだ問題は多いですね。
たとえば、Active DirectoryはまだすべてをLDAPでやっているわけではなくて、古臭いMSRPC（MicrosoftRemoteProcedureCall）トランスポート――つまり、NT4で使われているトランスポート――に依存する部分をかなり残しています。これには少なからず驚きました。Active Directoryのことを調べはじめたときは、もうほとんどのコールがLDAPに移されているものと思っていました。LDAPのほうがずっと柔軟性が高いですからね。ところが、Microsoft社はまだクライアントにMSRPCを多用しています。ま、たしかに、同じクエリをLDAPでやる方法も用意はされているのですが……。
Sambaから見たActive Directoryの最大の利点というと、’winbindd’デーモンでのLDAPコールがずっと柔軟になったことでしょうか。MSRPCベースのNT4ドメインでは、ドメインコントローラに対して行えるリモートクエリ群が固定されていました。たしかに、かなり大きなクエリ群ではありますが、必要なクエリが必要な形で含まれているとは限らず、不承不承、妥協せざるをえないことも少なくありませんでした。
たとえば、getpwent()というよく使われるPOSIXコールがあります。このコールでは、’winbindd’でドメインコントローラからユーザ一覧を取り出すほかに、各ユーザのプライマリグループも取り出してこなければなりません。これをNT4ドメインでちゃんとやるには、ユーザごとに個別のクエリをドメインコントローラ宛に出し、プライマリグループIDを取り出すことになりますが、そうするとたいへんな量のネットワークトラフィックが発生し、遅れが生じます。LDAPなら、どのフィールドを返させるかをクライアントがクエリの中で選択できますから、たとえば「全ユーザの一覧と、それぞれのプライマリグループIDを送れ」というクエリ1個で間に合います。効率のよさは段違いです。
Active Directoryの登場でSambaに突き付けられた問題としては、もう1つ、他のフリーソフトウェアプロジェクトとの連携があります。連携の必要性が格段に強まりました。もともと、Sambaはかなり独立したソフトウェアで、非コアのオペレーティングシステム・サービスにあまり依存せずに動作できましたが、Active Directoryの登場でそれが一変しました。いまでは、KerberosとLDAPとDNSが正確に動作してくれることが、Sambaの動作の大前提です。ですから、Sambaリリースを他パッケージのリリースと一致させることが、潜在的には問題となりえます。リリースが合わないと、ちょっとたいへんです。
こうした問題はありますが、Samba 3.0のActive Directoryサポートは満足できる出来映えだと思います。Samba 3.0のアルファ版は、もうかなりの企業で実稼動していて、Active Directoryドメインメンバとして使われています。それに、私の知るかぎり、2つのベンダがそれぞれのアプライアンス製品にアルファ版を同梱して出荷しています。ユーザからのフィードバックもたいへん勇気づけられる内容です。
SambaをActive Directoryドメインコントローラとして働かせる作業は、まだ開発の初期段階にあります。Jim McDonoughやAnthony Liguoriなど、これに精力的に取り組んでいる開発者が数人いて、進捗状況も目覚しいものがありますが、実働に堪えるものが出来上がるまでには、少なくともまだ数か月は必要でしょう。
Q：Active Directoryサポートでは、Active Directoryデータベースを破壊してしまう心配はありませんでしたか。なにしろ、ドメインサーバーごとにデータベースコピーがあるわけですからね。この点は問題になりませんでしたか。
これまでのところでは、問題というほどのことはありません。「ADSドメインメンバ」コードの開発でやっていることは、既存のMicrosoft ADSドメインコントローラに対する簡単なLDAPクエリにすぎませんからね。このクエリでLDAPデータベースが破壊されることは、まずないでしょう。
ADSドメインコントローラの開発の焦点は、いまのところ、スタンドアロンのドメインコントローラの作成です。したがって、破壊の危険はごく小さいと言えるでしょう。SambaドメインコントローラとMicrosoftドメインコントローラを1つのドメインに混在させることは、まだ先の話です。
もちろん、いざSambaドメインコントローラとMicrosoftドメインコントローラを1つのドメインに並存させる段階になれば、データベース破壊の問題を常に念頭に置かなければなりませんが、いまのところそれは大きな問題ではありません。
Q：オーストラリアではどうか知りませんが、アメリカでは企業の50%が小企業で、その多くはIT管理の概念などほとんどなくて、LANの用途もファイルとプリンタの単純な共有に限られています。SMBとNetBIOSの組み合わせは、たしかにいろいろな面で最適とは言えないでしょうが、ユーザフレンドリなLANブラウジングとピア間のリソース共有だけを目的としている小さなピアネットワークでは、この組み合わせでとくに不都合はなかったと思います。さて、SMBやNetBIOSをもう誰もほしがらなくなるとすると、将来、この組み合わせには何が取って代わるのでしょうか。
まず、SMBとNetBIOSの意味を少し明確にしておきましょう。ちょっと混乱を招きかねない用語ですから。
NetBIOSを、TCPやUDPと同レベルのトランスポートと考えている人もいますが、私自身はこれをNetBEUIと呼びたいですね。そのほうがNBT（’NetBIOS over TCP/IP’）と区別しやすいですから。で、SambaはそのNBTの実装です。
数年前まで、ホームネットワークやスモールオフィスネットワークでWindowsファイル共有をしていた人は、かなりの割合でSMB over NetBEUIを使っていました。ご指摘のとおり、これは小規模LANにはきわめて適していました。最小限の管理ですみますからね。コンピュータの1つ1つにIPアドレスを割り当てる必要もありません。同じ理由から、SMB over IPX/SPXを使う人もたくさんいました。
最近では、誰も彼もがSMB over TCP/IPを使っています。一つには、DHCPのおかげで、IPネットワークの管理がずっと簡単になったことがあるでしょう。もっと最近になると、ゼロ設定システムなどというものが出てきましたし、完全自動の――しかも、安い――ホームゲートウェイも出現して、DHCPで必要だったごくわずかな管理作業さえも不要になりました。もう、NetBEUIやIPX/SPXを使用する理由は、ほぼ完全になくなりつつあります。
SMBとCIFSの比較にも多少の混乱が見られます。最近、Microsoft社は自社のファイル共有プロトコルをCIFSと呼んでいて、SMBをあたかも古いプロトコルであるかのように扱っています。
事実はそうではなくて、SMBとCIFSは同じプロトコルです。名前の変更は、プロトコル名に’I’（Internet）を含めるためのマーケティング上の配慮でしょう。名前が変わってから、プロトコル自体にも多少の変更が加えられましたが、大きな変更ではありません。違いを言うなら、旧SMBプロトコルのバージョン間の違いのほうが大きいくらいです。
Microsoft社は、最近、いろいろな新しい名称を使うようになっていて、これが混乱に拍車をかけています。現在使っているのは次の3つです。
- SMB――もとのプロトコルのコア部分
- CIFS――わずかな変更を加えたプロトコル
- Microsoft SMB――プロトコルのコア部分と、Microsoft社独自の工夫（と同社が考えているもの）とを合わせたもの
もちろん、Sambaはその全部を実装しています。私たちの目標とするところは、あらゆるMicrosoftクライアントとのシームレスな相互運用です。これを実現するには、プロトコルの人為的なサブセットだけで満足しているわけにはいきません。
最後のご質問は、なかなか答えるのが難しいですね。SMBとCIFSの将来をどう見るか。私自身は、SMBもCIFSもかなり生き長らえるのではないかと思っています。もちろん、将来のどこかの時点で、Microsoft社が急に代替プロトコルの後押しを始めることは十分にありえます。ここ何年かで、たとえばWebDAVなど、いくつかの候補も浮上してきてはいますが、どれも、Windows LANのファイル共有市場を脅かすほどの力はもっていません。
Q: なるほど。では、LANのブラウジングに関してもう1つ質問させてください。4つのコンピュータをLANでつなげようというとき、IT管理者と呼べる人物がいなかったとします。先ほど説明していただいたように、DHCPと安価なルータを使えば、この程度のLANならほぼ無設定で構築できます。しかし、このケースでは、あるプロトコルが見落とされています。つまり、すべてのコンピュータがIPアドレスの代わりに名前を持ち、LAN内でブロードキャストによるアナウンスとそれに対する応答ができ、ユーザが簡単にローカルのリソースをブラウジングできるようにするプロトコルです。もし、将来的にデスクトップ版のLinuxができ、「Lindows」のような強力な対抗馬がなく、しかも、すべてがLinuxで構成されたネットワークの場合、Sambaがベストなソリューションとなり得るでしょうか。
Samba──正確には、Sambaの中でもNBTプロトコルに関する部分──もソリューションの1つになるでしょうが、それが唯一の選択肢ではありません。たとえば、スマートDHCPサーバを使うのも1つの方法です。スマートDHCPサーバは、DNSサーバとやりとりすることができるので、クライアントがDHCPからアドレスを取得したときに、クライアントの名前をDNSに自動的に登録してくれます。こういったやり方はごく一般的に行われています。標準のツールを使う場合には、こういった設定が多少面倒なこともありますが、将来的には、家庭用のゲートウェイで同様の機能がサポートされるようになると思います。
もう1つの候補は、OpenSLPで実装されているService Location Protocolです。ただ、このプロトコルがうまく受け入れられるかどうかは今のところまだわかりません。
ご質問のような名前解決にSambaとNBTを使うことには問題があるので、WindowsでないLANでベストな方法であると言えません。たとえば、名前が15バイト以内でなければならない、非ASCII文字をうまく扱えない、名前空間がフラットである、といった点は、どれもNBTが持つ大きな問題です。比較的簡単であることと、安定したフリーな実装がすでに存在することから、短期的にはアドバンテージがあるかもしれませんが、長期的に見た場合にSambaとNBTがお勧めするに足るソリューションとなり得るかどうかは断言できません。
Q: SMBのオーバーヘッドは、他の同様のプロトコルと比べてどうですか。
△SMBは大規模なプロトコルですので、このプロトコルの実装に必要なコードを単にメモリにロードするだけでも相当なオーバーヘッドがあります。そのため、SMBを組み込んだサーバでは、単純なプロトコルに比べるとより多くのメモリが必要になります。しかし、現在ではメモリの値段がとても安くなっていますので、これはさほど大きな問題ではないでしょう。
LANで稼働するごく普通の小規模サーバについて言えば、単にファイルを転送するだけなら、SMBのオーバーヘッドは非常に小さくなります。もちろん、よりオーバーヘッドの小さいプロトコルを設計することも可能ですが、普通に使う分にはそれほど違いは出ないはずです。
ハイエンドなギガビット・イーサネット・カードを装備する2台のコンピュータが通信する、あるいは高価なスーパー・コンピュータ・クラスタがハイパフォーマンスなネットワークでつながれている、というような特殊な状況では、SMBのオーバーヘッドがもっと顕著になるでしょう。しかし、これも実際にはそれほど問題になりません。このようなケースでは、一般的なファイル共有プロトコルを使わないからです。おそらく、専用のネットワーク・アーキテクチャが使われることでしょう。
Sambaに実装されたSMBのオーバーヘッドのうち最も注目すべきなのは、プロトコル自体に起因するオーバーヘッドではなく、SMBのセマンティクスがPOSIXのセマンティクスとうまく一致しないことにあります。Sambaでは、POSIXとSMBのマッピング処理に多くの時間を費やします。その最たるものが、大文字・小文字を区別するファイル名をWindowsクライアントで使えるようにする処理です。この処理は、非常にコストが高く、Sambaがやらなければならないことのうち最もオーバーヘッドの大きいものの1つです。さいわい、従来とは違った新しいセマンティクスをLinuxでサポートしようという動きがあります。これが実現すれば、こうしたオーバーヘッドを軽減するのに大きな効果があるでしょう。
Q: 以前、NFS over SMBを支持するような発言をよくされていましたが、この考えは今も変わりありませんか。また、どのような場合なら、SMBの代わりにNFSを使うべきであると考えていますか。
確かに、特定のアプリケーションでNFS over SMBを使うことは推奨していました。しかし、どのような場合にもNFS over SMBが有効であるとは言っていません。たとえば、2台のLinuxシステムで使うのなら、smbfsクライアントとSambaの組み合わせではなく、NFSを勧めます。しかし、Microsoftのクライアントまたはサーバが絡むときには、なんでもかんでもNFSを推奨しているというわけでは決してないのです。SMBは、Microsoftのどのオペレーティング・システムにも緊密に結合していますので、NFS over SMBを使える状況は限られています。
NFSのよい点は、そのシンプルさにあります。小さいプロトコルで、UNIXシステム同士では非常によく機能します。ただし、大きな弱点もいくつかあって、特に現在のバージョンのNFSは、首尾一貫性の面で危険な綱渡りをしています。
たとえば、NFSサーバを使うには少々我慢が必要で、ファイルを保存し、makeとタイプしても何も実行されず、しばらく待って、再度makeとタイプしてやっとビルドが始まる、ということがあります。この症状は、NFSで属性キャッシュ時間を使っているときに現れます。属性キャッシュ時間とは、簡単に言うと、数秒前の情報を有効と見なす機能です。現在のコンピュータが数秒間でどれほどの処理を実行できるか想像すれば、こういった考えはまったくナンセンスとしか言いようがありません。大切なデータを扱うには、ちょっと危険過ぎますね。
こうした部分は、NFSv4ですべて変更されるはずです。NFSv4は、NFSプロトコルを抜本的に見直すオーバーホールとも言えるもので、NFSv2やNFSv3と比べると、多くの意味でよりSMBプロトコルに近い存在となります。残念な点は、このプロトコルが以前よりもずっと大きくなってしまうことですが、SMBよりはすっきりとしたデザインになるでしょう。
NFSv4プロトコルの仕様が最初に公開されたとき、このプロトコルが将来的にファイル共有プロトコルのメインストリームになると期待していましたが、今ではその考えに疑問を持っています。問題の根本は、あまりに多くのプロトコルがオプション化されていることにあるようです。NFSv4に実装するプロトコルを自由に選択できることから、場合によっては、同じNFSv4同士でも満足にやりとりできないという事態が起こり得ます。これが、このプロトコルの普及を難しくしている要因です。
Q: あなたの経歴は、さながらLinux小史といったところですね。大学での研究から始まって、収益を目的としたLinux事業の立ち上げ（LinuxcareとVA Linux）、そして現在の職場であるQuantum社での仕事。おそらく、ここでもLinuxのエンタープライズ・ソフトウェアに携わっていることでしょう。たくさんの経歴と才能をお持ちのようですが、過去数年の間に専門家としてSamba関連の仕事に就いたことはありますか。
私の置かれている状況は、あなたが考えているよりもずっと悪いですよ。この間、また会社を移ったばかりです。昨年の10月にQuantum社がNAS部門を閉鎖したのに伴って、同社を辞めています。1年前に、VAがNAS部門を閉鎖したときにも部門の社員がいっぺんに解雇され、同じ憂き目に会いました。私にはどうやら、あまり長続きしない仕事を掴んでしまう才能があるようです。
現在は、CanberraにあるOzLabs研究所を仲介にして、IBMのAlmaden研究所に所属しています。今度は今までとは違います。絶対に1年以上続くと確信していますよ。NASの仕事はおもしろいし、特に研究のための環境が揃っているのがうれしいですね。
おっしゃるとおり、ここ数年の専門家としての活動で、Sambaが重要な位置を占めていることは確かです。しかし、私が取り組んでいるのはこれだけではありません。過去に働いたことがあるどの会社でも、求められることは何でもやろうとしてきました。Linuxのカーネル・ドライバの開発から、システムの構築、果てはGUIのコーディングまでやっています。そんな働き方をしていても、自分のやってきたことをオープンソース・ソフトウェアに活かすことができないか常に考えていました。企業に身を置きながらccache、tserver 、trdなどをリリースできたのは、その成果の1つであると思っています。
これらのパッケージはどれも、会社で製品を開発していたときの問題がヒントになっています。これらのパッケージが他の人々に利用されていることを喜ばしく思いますし、自分の書いたコードがフリーソフト・コミュニティに貢献できるのを知って、とても満足しています。
Q: Sambaプロジェクトは、オープンソースと私企業との共益関係としてよい例だと思います。企業がWindowsネットワークを利用したいときには、Sambaプロジェクトのプログラマを雇えばいいわけですし、うまくいけばSambaベースのソリューションを実装するための専門知識も得られます。実際のSambaプロジェクトもこのような感じだったのですか。
プロジェクトの発足当時は、そうではありませんでした。ほとんどの人が、純粋に趣味としてやっていたからです。しかし、ここ数年は状況が大きく変化しています。現在は、Samba開発者の多くが企業に所属し、その企業の製品でSambaが使われたり、何らかの形でSambaがビジネスに利用されたりしています。これらの企業とSambaチームとの関係はきわめてインフォーマルでありながら、非常に生産的です。各個人は、Sambaの特定の分野に取り組むべく会社に雇われますが、企業のニーズはそれぞれ千差万別なので、全体としては非常にバランスよく仕事が回ります。
Q: 現時点で、SambaはWindows NT 4.0ドメインと、例外なしで100%の互換性があるでしょうか。Windows NT 4.0 Serverの代わりにSambaを使っても、ネットワークの相互運用性という点で問題はないのでしょうか。
100%互換性があるものなど、そもそも存在しません。同じWindowsのリリース違い、あるいはサービスパック違いでさえ、完全には互換性がないのです。長年Windowsの管理者をやっていれば、誰でも知っていることです。残念なことではありますが……。
Sambaは、ファイル/プリント・サーバとして非常に優秀です。Windowsとの互換性は申し分なく、Windowsクライアントへ信頼性の高いファイル/プリント・サービスを供給するサーバとして、非常に多くのサイトで使われています。
もちろん、これでSambaが完璧というわけではないので、より多くの機能をカバーし、よりよいパフォーマンスを発揮できるよう、絶えず改良を続けるつもりです。現時点では、同じドメインにSambaのドメイン・コントローラとMicrosoftのドメイン・コントローラを混在させることはできませんから、このあたりが改良すべきポイントとして有力です。こういったニーズを抱えているところは少数でしょうから、さほど重要な問題ではありませんが、将来的に実現していきたいことの1つとして考えています。この種の機能がないとSambaを使えないような場合には、貴重な存在となるはずです。
Q：現時点のSambaは、Windows NT 4.0ドメインと例外なく100%の互換性があるのですか。ネットワークの相互運用性という点で、SambaをWindows NT 4.0 Serverと相互に置き換えることは可能ですか。
100%の互換性なんてこの世にありませんよ! Windowsだってバージョンやサービスパックが違えば100%の互換性はないことは、長年Windowsの管理者をやっていれば常識です。
私に言えるのは、Sambaが優れたSMBファイルサーバであり、プリントサーバだということです。Windowsとの高い互換性を備え、膨大な数のサイトに導入され、高い信頼性を誇るファイルサービスとプリントサービスをWindowsクライアントに提供しています。
もちろん、まだやるべきことは残っています。新しい機能を追加したりパフォーマンスを向上するために、Sambaの改良を常に続けています。たとえば、今はSambaドメインコントローラとMicrosoftドメインコントローラを同じドメインに混在させられません。そうしたいと思わない人が多いので大きな問題ではないのですが、将来的にはサポートする可能性があります。この機能がないとSambaを使えないサイトにとっては重要なことですからね。
Q：最近、Sambaにセキュリティの問題が見つかりました。ファイアウォールを経由せずに直接インターネットに接続されているコンピュータでSambaを使うのは安全でしょうか。
必要なネットワークサービスだけをインターネットから見える状態にするべきです。Sambaだけを特別扱いする理由はありません。Sambaは複雑なので、ほかのプロトコルサーバよりもリスクが大きいとお考えかもしれませんが、最近のバグを発見したSuSEの技術者のように、たくさんの人々がSambaのセキュリティホールを調査しているからそう見えるに過ぎません。
最近見つかったセキュリティホールに関する勧告の中で、私はネットワーク内部からの接続しか許可しないことでSambaの露出を減らす方法を文書にまとめました。この対策を実施すれば、リスクは減ります。
Q：真偽はともかくとして、Windowsのセキュリティには悪評があります。Sambaのせいで、*nixシステムがWindowsシステムの不名誉な脆弱性に脅かされる可能性はないのでしょうか。
いいえ、Sambaをインストールしただけでセキュリティが損なわれることはありません。Sambaに実装されたプロトコルが、SSHのようなプロトコルほど偏執的な注意力をもって書かれてないのは確かに事実です。だからといって、Sambaへの侵入がたやすいわけではありません。それに、WindowsにセキュリティホールがあるからSambaにも同じ穴があると考えるのは筋違いです。実際、WindowsのセキュリティホールがSambaにも見つかるという事態は、私には想像できません。同じコードを共有するなら両方に同じセキュリティホールが見つかってもおかしくはないでしょう。もちろん、WindowsのソースコードはSambaに使われていないので、これは問題外です。
Q：これまでの経験から、オープンソース・プロジェクトの資金獲得方法について、どういった印象や意見をお持ちですか。
技術よりも資金調達に熱心なオープンソース・プロジェクトを見ると、いつも首を傾げてしまいますね。ほとんどのプロジェクトは、資金ゼロか、わずかな資金で成功しています。初期の目標として資金獲得に高い優先度を与えてスタートしたプロジェクトが早々に衰退し行き詰まるのを、私は幾度となく見ました。フリーソフトウェア・コミュニティは、特定の1つの資金モデルではなく1人1人の貢献者の熱意に支えられているのです。
資金など役に立たないと言いたいわけではありません。プロジェクトの生き残りに必要な場合もあります。ポイントは、プロジェクトから恩恵を得られる企業なり組織を見つけ、彼らの立場から見てビジネスとして有望な提案を持ちかけることです。たとえば、それはプロジェクトに携わる誰かを雇用することかもしれませんし、カンファレンスに出席する誰かの経費を負担することかもしれません。あるいは、Webホスティングなどのサービスの運営費を出すことかもしれません。そういったことはどれも非常に有益な貢献ですが、資金の獲得に時間をかけすぎてプロジェクトのほかの活動がおろそかになるのは本末転倒です。
Q: Sambaプロジェクトは、ほかのWindows相互運用性プロジェクトとどの程度連携しているのですか。たとえば、 Wine やMono とは。
密に連絡を取り合う関係ではありません。各プロジェクトのメンバーが意見を交換することはありますが、かなり特別なことです。今度は増える可能性があります――特にコードの共有化が始まれば。コード共有が検討されているのは、WineツリーのWIDLコンパイラなどです。Samba MSRPCコードに興味深い可能性を提供する活動ですね。SambaでWIDLを使うことになれば、Wineの開発者ともっと頻繁に意見を交換することになるでしょう。
Q：有名なオープンソース・プロジェクトを多年に渡って運用してきた立場から、オープンソース・プロジェクトの管理に関して、向上心あふれるプロジェクトマネージャに何かアドバイスはありますか。
私はかなりの放任主義です。怠け者だというのも理由の1つですが、それでうまくいくとわかっているからでもあります。オープンソース・プロジェクトを管理するのは、普通のビジネスを管理するのとは違います。本人がやりたがっていることを頼む――できるのはそれだけです。気が進まないことまで無理強いはできません。自発的にプロジェクトに参加している人がほとんどなのですから。
実を言うと、定期的にしている活動のどれを”管理”と呼んでいいのか、よくわからないのです。技術的な討論に参加し、コードを書く、それが私の仕事のすべてです。プロジェクトの発起人ですから討論の場ではほかのメンバより発言力は多少大きいのですが、それをいいことに意見を押し付けるようなことをすれば、そんな権威などあっという間に色あせてしまうでしょう。
ほかのフリーソフトウェア・プロジェクトのリーダーの中には、ずっと積極的な姿勢でプロジェクト管理に臨む人もいます。それでうまくいっているならいいのです。私はそういったやり方に興味がないというだけです。
Q：Webページにメールアドレスを載せることさえ珍しかった時代に、あなたは自宅の電話番号を載せていました。なぜですか。どんな電話がかかってきたのですか。
ほとんどの人にとって国際電話の料金はたいした負担ではないのに、意外なほどかかってきませんね。最初に電話番号をホームページに載せたときは、Sambaに関する質問の電話が鳴りっぱなしになると思いました。質問メールは山ほど来ていましたから。実際には、2週間に1本程度しか電話はありません。それも、本当に急ぎの用件があって、電話するだけの十分な理由がある人からがほとんどです。Sambaのビジネス利用に関するとても興味深い意見の一部は、こういった電話での問い合わせから得られます。今でも電話番号を記載しているのは、それが理由です。もし問題があっても、消すのはいつでもできますから。
Q: どのLinuxデストリビューションを愛用してますか。
いつも使っているのは、Debian とRed Hat の2つだけです。個人的にはDebianが好きですね。開発マシンでは、2週間ごとにDebian 「unstable」をアップデートしてますよ。
ほかのマシンではRed Hatを使っています。Red Hatを使い慣れた人と管理を共有する必要があるからです。たとえば、メインのsamba.orgサーバではRed Hatが動いてますが、APT for RPMアドオンを利用してDebian aptシステムによる安全なリモートアップデートを使っています。samba.orgサーバにRed Hatを使うことにしたのは、このサーバが地球の裏側のデータセンタにあり、何か異常が起きた場合を考えるとデータセンタのエンジニアが使い慣れたデストリビューションの方が都合が良いからです。
Q：Linuxは多方面で成功を収めていますが、それにつれて要求のハードルが上がり、取り組む課題が全般的に複雑化しているので、調整や共同作業が以前よりも必要となっています。Linuxコミュニティの健全性についてどう思いますか。Linuxが向かうべき方向について、何かお考えはありますか。
Linuxコミュニティは繁栄していると思いますよ。これからも本当に価値のある存在として繁栄を続けるでしょう。Linuxベースのビジネスから利益をあげようとしている企業が成功を収めるかどうかは確信がありませんが、幸いなことに、成功してもしなくても、私が関心を寄せている部分のLinuxコミュニティの存続に影響はないでしょう。そう考えると、Linuxの未来は非常に明るいと思います。
Q：オーストラリア国内のLinux事情はどうですか。
ひとり立ちしていると表明するのは時期尚早ですが、それを除けばLinuxはオーストラリアでとてもよい状況にあります。Linuxユーザグループは成長を続けていますし、Linuxが政府機関や企業にプラットフォームとして認められる日が近いことを示す材料も増える一方です。
最近Perthで開催されたカンファレンスは大成功でした。特に、技術的な内容よりもスポンサーや企業の支援獲得に向かう誘惑に打ち勝った数少ないカンファレンスでした。おかげで、すばらしい発言者たちが集まり、とても興味深い技術的な討論が盛り上がりました。Linuxカンファレンスのお手本です。
Q：以前の発言で、ご自分のほかのプロジェクトrsync が長期的にはSambaの後まで残り、Sambaの地位は低下するとおっしゃいましたね。rsyncはこの予想通りに進んでいるのでしょうか。
その見解は、rsyncアルゴリズムとその背景にある着想について言ったもので、rsyncツールそのものについてではありません。今も考えは変わりませんよ。rsyncとdelta圧縮は、幅広いコンピューティングタスクに影響を与える途方もない可能性を秘めた新進の技術ですから。その点でSambaとは大いに違います。Sambaは、極めて限定的なクライアント相互運用のための存在にすぎません。また、Sambaには、コンピュータサイエンスの観点から根本的に新しいとか画期的な点は何もないのです。このことから、Sambaの長期的な展望はかなり限定されます。
Q：Active DirectoryがSambaでサポートされるまで数年かかりました。これまでのプロジェクトの経過から、SambaがWindowsネットワーキングの重大な変更に対応する能力をどう評価しますか。新機能のサポートにあたり、リソースと需要のどちらを重視するのですか。ネイティブWindowsとSambaとの互換性のギャップは、今後は小さくなるとお考えですか。
ギャップは確実に小さくなっています。この傾向はこれからも間違いなく続きます。特にSamba4ではそれを狙っています。
Active Directoryメンバのサポートですが、作業そのものは約6か月で完了しました。Windows 2000のリリースを待ってから作業にとりかかったのが遅れた理由です。ADS作業の開始が遅れたのは、ご指摘のとおりリソースと需要からの圧力によるものです。当初はNT4ドメインサポートだけで足りるユーザがほとんどだったため、NT4ドメインサポートの利用を完全にやめたネットワークの管理者から要望の声があがるまで、直接のADSメンバサポート追加の優先度は低いままでした。優先度が大幅に引き上げられてからは、作業は迅速に進められました。
Q：DeveloperWorksの最近のインタビュー で、あなたは冗談で、Sambaがいつか不要になることを願うと言っていますね。これはSambaチームというよりマイクロソフトの姿勢にかかっていることですが、いつかはそうなると思っていますか。
ええ、そう思いますよ。いつなくなるかはわかりませんが、Sambaのプロトコルは永久不滅ではありません。SMB/CIFSの利用者はいまだに増えていますが、マイクロソフトがいずれは別のファイル共有プロトコルに切り替えるのは確実でしょう。
Sambaが最後を迎える別のシナリオがあるとしたら、Microsoft Windowsをコンピュータにインストールする人がいなくなった場合ですね。実に最高の結末ですが、当てにはしてませんよ。
Alexander Antoniadesはニューヨーク市在住のハイテク職人。長年培った経験を活かし、同地での暮らし向きは比較的快適。
