これは、UNIX上でのSMB実装で直面するいくつかの問題について記述し、Sambaがどのように それらを実装したかを説明した短い文書である。これらはUNIX<->PC間の相互運用を 調べる人の手助けになるかもしれない。

PCへの接続機能を、UNIX上で実装している人の手助けとなるように書かれた。

SMBプロトコルはおおざっぱなユーザー名の概念しか持っていない。初期のSMBプロトコル (たとえばCOREとCOREPLUS)では、まったくユーザー名の概念がなかった。そのあとの プロトコルでもクライアントはしばしば(特にプリンターの操作において)、サーバー上で 最初にユーザー名を検証しないで運用をしていた。

UNIXのセキュリティは、ユーザー名/パスワードペアを基本としている。UNIXマシンは ある種の認証なしには、どのような実質的な操作もクライアントには許可しない。

UNIXサーバーが"共有レベル"でのセキュリティモードになっていたときに、主に問題が 発生する。これは多くのサイトで不評である、各接続済の共有に対して同じユーザーとして クライアントがサーバーに接続する事を通常強制する、"ユーザーレベル"セキュリティモードの 代替となる既定値のモードである。

"共有レベル"セキュリティでは、クライアントは通常"session setup"プロトコル中に おいて、ユーザー名を提供するが、対応するパスワードは提供しない。クライアントは 次に"tree connect"プロトコルを使ってリソースに接続し、パスワードを提供する。 問題は、PC上のユーザーは異なった場面でユーザー名とパスワードを入力することであり、 サーバーにアクセスする時に、両方を一緒にする必要があることを知らないということである。 ユーザー名は通常PCに"ログオン"するときに入力する(これはWindows for Workgroupを 仮定している)。パスワードはディスクやプリンターに接続するときに選択する。

ユーザーは、しばしばドライブの接続のためのログオンに、全く異なったユーザー名を選ぶ。 しばしば、異なったドライブに異なったユーザー名でアクセスすることも望む。UNIX サーバーは各パスワードに結びつけるための正しいユーザー名を何らかの方法で見極める 必要がある。

Sambaはこの問題をいくつかの方法を使って防ごうとする。それらは大変多くの場合、 成功する。その方法にはusername map、service%userという書式、後の認証のために session setupのユーザー名を保持してサービス名からユーザー名を判断する(directoryか user=オプション経由で)などがある。

通常使われるSMBプロトコルは、"ファイルを所有していないのでその操作はできません" という事を通知する方法を持っていない。要するに、全くファイルの所有権という概念が ないのである。

これは、ある種の興味深い問題を引き起こす。たとえば、UNIXマシンにファイルをコピー し、ファイルは誰でも書き込み可能(world writeable)だが、他のユーザーで所有されている 場合、ファイルは正しく転送されるが、間違った日付を受け取ることになる。これは、 UNIX配下ではutime()システムコールは、たとえファイルがすべてのユーザーに対して 書き込み可能だったとしても、ファイルの所有者かrootでのみ成功するという理由による。 セキュリティ上の理由により、Sambaはすべてのファイル操作を認証したユーザーの権限で 行い、rootでは行わないので、utime()が失敗する。これは"make"のようなプログラムが ファイルの時間を正しく取れないということで、共有された開発ディレクトリが不整合になる 可能性がある。

この問題に対するいくつかの解決方法があり、その中には、ユーザー名のマップと 特定の共有に対して特定のユーザー名を強制する方法などがある。

多くのSMBクライアントは送信前にパスワードを大文字にする。なぜそうなっているかの理由は 知らない。興味深いことに、WfWgは、COREPLUSよりもレベルが高いプロトコルで動いている時のみ パスワードを大文字にするので、データ入力ルーチンに責がないのは明白である。

UNIXパスワードは大文字小文字を認識する。そのため、もしもユーザーが大文字小文字を混ぜた パスワードを使う場合には問題が生じる。

Sambaは、大文字小文字を、指定された値まで変更しつつ、提供されたパスワードをSambaに 試行させる、"password level"オプションを使うか、他のマシン(通常Windows NTサーバー) 経由でこの検証をSambaに行わせることが出来る、"password server"オプションを使うことに よって、対処することが出来る。

SambaはSMBクライアントによって提供されるパスワード暗号化方法をサポートする。 Microsoftネットワークにおける暗号化パスワードの使用は、"平文と同等の" パスワードハッシュを提供することと同等であることに注意。これは、それらの パスワードハッシュを含むSambaのsmbpasswdファイルは、rootのみ読み出し可能に すべきであることが*とても重要*であることを意味する。詳細は ENCRYPTION.txtを参照のこと。

Samba 2.2以降、Sambaは他のロック方法をうまくサポートしている。この節は 時代遅れである。

DOS/Windows環境におけるロック呼び出しはunix上でのものよりも機能が豊富である。これは、 SMBのロックを実装するために、fcntl()ベースの標準UNIXロック呼び出しを使うことを選択する (Sambaのような)UNIXサーバーは、多少間に合わせで作る必要があるということである。 The locking calls available under a DOS/Windows environment are much richer than those available in unix. This means a unix server (like Samba) choosing to use the standard fcntl() based unix locking calls to implement SMB locking has to improvise a bit.

大きな1つの問題は、DOSのロックは32ビット(符号なし)の幅で行えると言うことである。 UNIXのロック呼び出しは32ビットだが、符号着きであり、31ビット幅しかない。 不幸にも、OLE2クライアントはOLEセマフォのためにロック幅を選択するためにトップ ビットを使う。

この問題に対応するために、Sambaは、適切なビットシフト操作を行うことによって、 32ビット幅を31ビット幅に圧縮する。これは動作するように見えるが、理想的ではない。 将来のバージョンでは、この問題に対処するために、分離されたSMBロックが追加される かもしれない。

多くのUNIXロックデーモンは結構バグがあり、些細なことによってクラッシュすることも 足を引っ張っている。通常、ごくわずかのUNIXプログラムしかバイトレンジロックを使わない という理由で、UNIX環境では、これらは通常ほとんど使われない。DOS/Windowsからクライアント からの非常に大量のロック要求の負荷は、ある種のシステムにおいてはデーモンを終了して しまう。

2番目の大きな問題は、ある種のクライアントから要求される"便宜的ロック(opportunistic locking)" である。もしもクライアントが便宜的ロックを要求した場合、同じファイル上に、他の誰かが 何らかの操作を行おうとしているならば、クライアントがそのロックを開放することを 告げる時、そのことを通知するためにサーバーに要求する。UNIXは便宜的ロックを簡単に実装する すべがなく、現在のSambaはそれをサポートしていない(訳注:古い)。

SMBクライアントがファイルをオープンするとき、ファイル上に設定されている特定の "拒否モード"について問い合わせをする。それらのモード(DENY_NONE, DENY_READ, DENY_WRITE, DENY_ALL, DENY_FCB と DENY_DOS)は、他の誰かが同じ時に同じファイルを使うときに許可 すべき動作を指定する。たとえば、もしもDENY_READがファイル上に設定されている場合、 読み取りのためのファイルへのオープン操作は失敗する。

UNIXは同等の概念を持っていない。これを実装するため、Sambaはファイルのinodeをベースとする ファイルのロックと、ロックディレクトリを分離するか、あるいは、共有メモリ実装を使う。 ファイルロックによる方式は、あまりかっこよくなく、処理のコストがかかりファイルリソースを 消費するが、共有メモリ実装は非常に好ましく(訳注:preferedはミススペル)、それをサポートする システムでは既定値で有効となっている。

SMBセッションは、1つのソケット上でいくつかのUIDを使って動作することが出来る。これは、 ユーザーが、異なったユーザー名で2つの共有に接続するときに起きる。これに対処するために、 UNIXサーバーは1つのプロセス内でUIDを切り替える必要がある。ある種のUNIX(たとえばSCO)では、 このようなことが出来ない。これは、そのようなUNIXでは、クライアントは単一のUIDでの処理に 制限されることを意味する。

その他の理由により、"trapdoor uid"メッセージも受け取る事があり得ることに注意。 詳細はFAQを参照のこと。

ソケット上のクライアントは、ポート番号が大きな値(>1000)の"非特権"ポート番号を使い、 サーバーへの接続は小さな値の"特権"ポートを使うという慣習がある。これは、UNIX上では、 1000よりも小さなポート番号上で、非rootなユーザーが、リッスンのためにポートを 開けないようにさせている。

ほとんどのPCベースのSMBクライアント(たとえばWfWgとWinNT)はこの習慣を完全に守っていない。 主犯はUDPのポート137でのNetBIOSの名前解決である。名前問い合わせ要求はソースポート137 から来る。これは、小さな(低位の)ポート番号で入ってくるパケットを許可しないよくある ファイアウォールの設定を使うときに問題になる。これは、それらクライアントは、低位の ポートベースのファイアウォールの反対側にあるNetBIOSネームサーバーに問い合わせできないことを 意味する。

NetBIOSノードステータスの問い合わせにおいては問題はより深刻である。WfWg、Win95と WinNT3.5のすべてが、要求元のソースポートが何であっても、ポート137上でNetBIOS ノードステータスを返す。これは両者ともポート137を使うマシン間では動作するが、 UNIXユーザーが、その種のOSでrootとして動作していない限り、ノードステータスを処理 出来ないことを意味する。答えに戻ると、ポート137はUNIXユーザーがリッスンできない。 興味深いことに、WindowsNT3.1ではこれが出来る。これは、要求中のソースポートに ノードステータスを返信する。

SMBプロトコルには数多くの"プロトコルレベル"がある。MicrosoftのOSに新しい機能が追加された たびごとに、新しい能力を"具現化"するために、SMBプロトコルの新しいプロトコルレベル中に 同等の機能を追加しているように見える。

これは、プロトコルは非常に"肥大化していて"、各ファイル操作に対して種々の方法を提供 していることを意味する。これは、SMBサーバーが複雑で肥大化してしまうことを意味する。 また、サーバーのバグをなくすことがとても困難であることも意味する。この問題で苦しむのは Sambaだけではなく、すべての呼び出しのすべての相違をサポートしないWindowsNTのような、 他のサーバーでもありえ、有効な無数のSMB呼び出しをサポートするためにMicrosoftの開発者に とっては全く持って頭痛の元である。

65種類もの(たとえばSMBreadとSMBwrite)のような"最上位の"操作がSMBプロトコル中にある。 それらのいくつかは数百ものサブ機能を含んでいる(SMBtransは少なくとも120の サブ機能を含み、たとえばそれらはDosPrintQAdd と NetSessionEnum)。それらのすべては その動作を変えるいくつかのオプションが指定できる。多くは、結果を返すのに必要と される、構造体を変更する"情報レベル"が何十種類もありえる。Sambaは2つの"最上位の" 機能を除いてすべてをサポートする。それは、SMBtransサブ機能の8つのみ(これまでの所) をサポートする。NTでさえ、全部をサポートしない。

Sambaは現在Windows95とWindowsNT3.5によって提供されている"NT LM 0.12"プロトコルまでを サポートしている。幸運なことにこのプロトコルレベルは、サーバーがサポートする、 とびきりの、新規なオプションを指定する"capabilities"フィールドを持っている。 これは、このプロトコルレベルの実装をより容易にすることを手助けしている。

また、SMBの仕様による問題もある。SMBはX/Openの仕様であるが、X/Openの書籍は理想的 からほど遠く、多くの重要な項目が欠落していて、多くを推測しなければならない。 Microsoftは最近SMBプロトコルをCIFS(Common Internet File System)と改名し、 新しい仕様を公開した。それは古いX/Openのドキュメントと比べると、とても優れているが、 引き続き文書化されていない呼び出しと機能が残っている。この仕様は、Microsoftによって 提供されているCIFS開発者メーリングリストによって活発に作業されている。

この文書にはNTサーバーを使わないでNTワークステーションのログオンサービスを提供するための 情報が記述されている。これはLukeによって管理されている、 http://mailhost.cb1.com/~lkcl/cifsntdomain.txt のsgmlバージョンである。

(NTワークステーションのTCP/IP設定中で)ワークグループの代わりにドメインを選択することは 可能であり、必須である再起動後に、ユーザー名とパスワードを入力し、ドメインを選択すれば 正しくログオンできる。この文書に対する、上記作業の経験からの、何らかのフィードバック 、何らかのコメント、修正と追加事項は歓迎する。

ここで説明するパケットはNetmon.exeによって簡単に(そしておそらくそれを使うことでより よく理解でき)得られる。NETLOGON、lsarpcとsrvsvcトランザクションパイプを正しくデコード するために、使用しているシステムに一致するNetmonのバージョンを使う必要がある。 この文書は、NTサービスパック1の、それに適合したバージョンのNetmonから得られている。 これは、この文書よりもより有益であろう、注釈付きのパケットトレースが生成されることを 目的としている。

また、NTドメインログオンサービスを完全に実装するため、NTの認証の暗号化部分を 説明する文書も必要である。この文書は comp.protocols.smbから公開されている、 ntsecurity.net のからの要約とsamba digestからとその他のソースからのものを使っている。

コピーは以下にある:

http://ntbugtraq.rc.on.ca/SCRIPTS/WA.EXE?A2=ind9708;L=ntbugtraq;O=A;P=2935

http://mailhost.cb1.com/~lkcl/crypt.html

Linus Nordbergによる、 このプロトコルに関するC言語での実装は、以下にある:

http://samba.org/cgi-bin/mfs/01/digest/1997/97aug/0391.html

http://mailhost.cb1.com/~lkcl/crypt.txt

デバッグ情報の提供のためにはNT workstationのCheck Buildバージョンも必要であり、 NETLOGON中で完全なデバッグを有効にする。これは以下のようにして、REG_SZ レジストリーキーを 0x1ffffff に設定することで行える:

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

不正にレジストリを編集すると、使用しているマシンを動作不能にさせる 事になる。このプロトコルの不正な実装になる。上記の"Liability:"を参照のこと。

ネットワーク上の各パケットはAPI呼び出しにおいて固有のオリジンを持っていることを 心にとめておくこと。そのため、その定義がほかの所で便利に文書化されている、 構造体や列挙型かもしれない。

この文書は、決して完全でも正式でもない。以下のようものだけではなく、 抜けているところがある:

名前付きパイプ上のSMBトランザクションの詳細はcifs6.txtを参照。

        initial SMBopenX request:         RPC API command 0x26 params:
        "\\PIPE\\lsarpc"                  0x65 0x63; 0x72 0x70; 0x44 0x65;
        "\\PIPE\\srvsvc"                  0x73 0x76; 0x4E 0x00; 0x5C 0x43;

abstract (0x4B324FC8, 0x01D31670, 0x475A7812, 0x88E16EBF, 0x00000003)
transfer (0x8A885D04, 0x11C91CEB, 0x0008E89F, 0x6048102B, 0x00000002)

switch (info class)
case 3:
case 5:
{
DOM_INFO domain info, levels 3 and 5 (are the same).
}

return    0 - indicates success

このパイプ上の動作の順番は以下の通り:

このパイプの定義のための、問い合わせ識別子は以下の通り

if (valid_user)
{
	UINT16      3 - switch value indicating USER_INFO structure.
    VOID*     non-zero - pointer to USER_INFO structure
    USER_INFO user logon information

    UINT32    1 - Authoritative response; 0 - Non-Auth?

    return    0 - indicates success
}
else
{
	UINT16    0 - switch value.  value to indicate no user presumed.
    VOID*     0x0000 0000 - indicates no USER_INFO structure.

    UINT32    1 - Authoritative response; 0 - Non-Auth?

    return    0xC000 0064 - NT_STATUS_NO_SUCH_USER.
}

注意: mailslotsはレスポンスmailslotを含み、それは送信されるべきレスポンスである。 ターゲットのNetBIOS名はREQUEST_NAME<20>であり、ここで、REQUEST_NAME はリクエストを送信したマシンの名前である。

このパイプのための定義で、クエリの識別は以下の通り:

SIDとRIDはどこかで詳細に説明がある。

SIDはNTセキュリティID(DOM_SID構造参照)である。これらは以下の形式を取る:

現在、SIDのリビジョンは1である。 Sub-Authoritiesは相対ID(RID)として知られている。

この文書は、内部的にSambaがどのように動くかについての一般的な概要を説明している。 Samba Teamは、非常に汚いSMBとCIFSプロトコルによって押しつけられる、優雅さ、セキュリティと 制約の間で、最も良い妥協点であるモデルを見いだそうとした。

また、以下のようなよく聞かれる質問のいくつかに答えようともしている:

人々は時々、一様にスレッドを良いものとして推奨する。それらは推奨する人にとっては とても良いものであるが、smbdに取ってはまったく不適当である。nmbdは別の問題で、 マルチスレッドそれ自身はとても良いことである。

手短に言うと、smbdはマルチスレッド化されておらず、UNIX配下での別のサーバー(例えば、 書いている時点においてはSyntax)はこの方法を取っていて、とても大きな性能上の問題を 抱えていて、頑丈ではない。nmbdもスレッド化されていないが、これは、35以上もの プラットフォームにまたがって、コードの整合性を取り、ポータブルにするということが、 不可能だからという理由である(この欠点は同じくsmbdをスレッド化することにも当てはまる)。

より長い期間において、smbdをマルチスレッドにしない、とても良い理由が存在している。 マルチスレッドはSambaをより遅くし、スケーラビリティを減少させ、移植性をなくし、 とても不安定にさせる。実際、各接続に対して独立したプロセスを使用していて、それは Sambaの最も大きな利点の1つである。

スレッド化したsmbdから発生するいくつかの問題は以下の通り:

これは理想ではあるが、ポータビリティの要求により実現するのは難しい。

Andrew はANSI-Cの範囲のみを使って(setjmpとlongjmpを使って)nmbd用のテスト用 スレッドライブラリを加工とした。残念なことに、いくつかのOSでは、スタック上の 現在のアドレスよりも浅い位置のアドレスを呼び出すためにlongjmpを制限することに よって、うまくいかなかった(見たところでは、AIXがそうである)。これは、真に ポータブルなスレッドライブラリを不可能にしている。そのため、現在対応している すべてのプラットフォームに対して、nmbdのコードをスレッドあり、なしの両方用意 しなければならず、スレッドの本来の目的はコードをきれいにすることであるが、 それを得られない(スレッドが物事を早くするというのは神話である。スレッドは 再帰のようなものであり、物事をきれいにするが、他の何らかの方法によって、いつでも それはもっと早くすることもできる)。

Chrisは、スレッド対独立したプロセス(対他の方法?)を要約する汎用的なデザインを設計 しようとし、いくつかの汎用APCを通して、それらをアクセス可能にした。これは、 プロトコルによるデータ共有要求(現在のパケットに将来のパケットが依存するなど)という 理由でうまく動かなかった。少なくとも、コードは動いたが、非常にぎこちなく、 その上、fork()タイプモデルは、UNIX上では決して動かなかった(nmbdに対して、 それが動くOSはあるのだろうか?)。

fork()は安っぽいが、受信したすべてのUDPパケット上で処理を行うのに、十分 安っぽいわけではない。プロセスのプールを持つことは可能であるが、プロセス間で、 (複雑な構造体中で)共有された巨大な量のデータのために、プログラムをきれいにする ことは、ひどく難しい。各プラットフォームが共有メモリシステムを持つ事を あてにすることは出来ない。

もともと、Andrewは、途方もなくスタックを使い、全くもってデバッグ作業を混乱させる、 マルチスレッド環境をシミュレートするための再帰を使った。Luke Leightonは各パケット上で ステート情報を保持する問い合わせシステムを使うように書き直した。最初のバージョンは、 すべての待機状態ステートによって使われる単一の構造を使っていた。この構造の初期化は、 引数を追加することで行われ、機能が開発するに従い、だんだん複雑化していった。 そのため、より高位の関数と、ユーザーが定義したメモリブロックを指定するポインターによって 置き換えられた。これは突然物事をより簡単にした:非常に多数の関数は静的に作成され、 モジュール化された。これはNTカーネルで使われているものと同じ原理であり、単一の プロセス中ではあるが、スレッドと同じような効果が成し遂げられた。

次に、Jeremyはnmbdを書き直した。nmbd中のパケットデータはネットワーク上のものではない。 この形式は、処理に対してとても従順なものであるが、まだ他のパケットの内容を保持していた。 nameserv.h中の"struct packet_struct"を参照のこと。そこにはすべての詳細があるが、 ネットワーク上のメッセージについては記述がない。これは、ブラウジングとWINSサポートの ための、ディスクかメモリベースのデータベース中で理想的に使えるようにする。

デバッグログファイルの文法は以下の通り:

  >debugfile< :== { >debugmsg< }

  >debugmsg<  :== >debughdr< '\n' >debugtext<

  >debughdr<  :== '[' TIME ',' LEVEL ']' FILE ':' [FUNCTION] '(' LINE ')'

  >debugtext< :== { >debugline< }

  >debugline< :== TEXT '\n'

TEXTは改行文字を含まない文字列である。

LEVEL はメッセージのDEBUGレベルである(0から10の範囲の整数値)。

TIME はタイムスタンプである。

FILE はでバグメッセージが生成されたファイルの名前である。

FUNCTIONはデバッグメッセージが生成された関数である。

LINEはメッセージが生成されたデバッグ文の行番号である。

基本的に、それが意味するところは以下の通り:

出力の例:

    [1998/08/03 12:55:25, 1] nmbd.c:(659)
      Netbios nameserver version 1.9.19-prealpha started.
      Copyright Andrew Tridgell 1994-1997
    [1998/08/03 12:55:25, 3] loadparm.c:(763)
      Initializing global parameters

上記の例において関数名はヘッダー行には表示されていないことに注意。これは、上記の例は SGI Indyによって生成され、SGIコンパイラは__FUNCTION__マクロをサポートしていないという 理由による。

DEBUG()マクロの使用は変わっていない。DEBUG()は2つのパラメーターをとる。 最初のものはメッセージレベルであり、2番目のものはDebug1()関数を呼び出すための 関数呼び出しの実体である。

これは混乱させる。

若干の手助けとなるかもしれない例は以下の通り。もしも

printf( "This is a %s message.\n", "debug" );

と書いて結果を標準出力に送りたいのであれば、 to send the output to stdout, then you would write

DEBUG( 0, ( "This is a %s message.\n", "debug" ) );

と書くことで、結果はデバッグファイルに送られる。すべての通常のprintf() フォーマットのエスケープ処理はちゃんと動作する。

上記の例において、DEBUGメッセージレベルは0に設定されていることに注意。メッセージレベル 0は常時出力される。基本的に、もしもメッセージレベルがグローバル値DEBUGLEVEL以下の場合、 DEBUG文は処理される。

上記の例の出力は以下のようなものになる:

    [1998/07/30 16:00:51, 0] file.c:function(128)
      This is a debug message.

おのおののDEBUG()呼び出しは、以前の呼び出しによって生成された出力の行末が、 "\n"で終わっていないならば、新しいヘッダーを作成する。デバッグファイルへの出力は、 改行が来るたびごとにフラッシュされるフォーマットバッファーを通して渡される。 もしも、DEBUG()が呼ばれたときにバッファーがからでなければ、新しい入力は単に 追加される。

...しかし、これは全くその場しのぎである。DEBUG()が分割された行を書き込むのに 使われると言う理由で、適切な位置に置かれる。以下は今説明したことに関する、 この種の簡単な例である:

    DEBUG( 0, ("The test returned " ) );
    if( test() )
      DEBUG(0, ("True") );
    else
      DEBUG(0, ("False") );
    DEBUG(0, (".\n") );

フォーマッティングバッファーなしでは、出力(test()がtrueを返すことを仮定)は以下のようになる:

    [1998/07/30 16:00:51, 0] file.c:function(256)
      The test returned
    [1998/07/30 16:00:51, 0] file.c:function(258)
      True
    [1998/07/30 16:00:51, 0] file.c:function(261)
      .

これは使い物にはならない。フォーマットバッファーというその場しのぎの方法は、 この問題を解決する。

上記で説明されている行が壊れてしまう問題への、その場しのぎの解決方法への追加として、 もっときれいな解決方法がある。DEBUGADD()マクロは決してヘッダーを生成しない。フォーマット バッファーがからであったとしても、これは現在のデバッグメッセージに対して新しいテキストを 追加する。DEBUGADD()マクロの文法はDEBUG()マクロのものと同じである。

    DEBUG( 0, ("This is the first line.\n" ) );
    DEBUGADD( 0, ("This is the second line.\nThis is the third line.\n" ) );

これは以下を生成する。

    [1998/07/30 16:00:51, 0] file.c:function(512)
      This is the first line.
      This is the second line.
      This is the third line.

DEBUG()マクロにおける問題の1つは、DEBUG()行が長すぎる傾向にあると言うことである。 nmbd_sendannounce.cからの以下の例について考えてみよう:

  DEBUG(3,("send_local_master_announcement: type %x for name %s on subnet %s for workgroup %s\n",
            type, global_myname, subrec->subnet_name, work->work_group));

この問題の1つの解は、DEBUG()とDEBUGADD()を以下のように使って行を分割することである:

  DEBUG( 3, ( "send_local_master_announcement: " ) );
  DEBUGADD( 3, ( "type %x for name %s ", type, global_myname ) );
  DEBUGADD( 3, ( "on subnet %s ", subrec->subnet_name ) );
  DEBUGADD( 3, ( "for workgroup %s\n", work->work_group ) );

同様だが、もっとすてきな方法は、DEBUGLVL()マクロを使う方法である。 このマクロは、メッセージレベルがグローバル値DEBUGLEVEL以下の場合に真を返すので:

  if( DEBUGLVL( 3 ) )
    {
    dbgtext( "send_local_master_announcement: " );
    dbgtext( "type %x for name %s ", type, global_myname );
    dbgtext( "on subnet %s ", subrec->subnet_name );
    dbgtext( "for workgroup %s\n", work->work_group );
    }

と書ける(dbgtext()関数は以下で説明する)。

この方式ではいくつかの利点がある:

この章では、Samba3.0以降におけるSamba内部での文字セットの取り扱いについて言及する。

以前のバージョンのSambaは、とてもその場しのぎの文字セット処理を行っていた。点在する コードはDOSのコードページへ、あるいはコードページから特定の文字列を変換するのに、 数多くの呼び出しが使われていた。問題は、特定のchar*がdosのコードページかUNIXの コードページかを確認するすべがないということである。これは、一般的な場合での取り扱いが ない、特定の場合に対応する事を試みる悪夢のようなコードになってしまう。

新しいシステムは以下のように動作する:

この節では、byteorder.h内で定義されているマクロについて説明する。それらのマクロは Sambaのコード内で広範囲に使われている。

この節では、LANマネージャRPCコールを行わせるのに必要な関数について説明する。 この情報はSambaコードの調査とLANマネージャ 2.0APIのドキュメントに依存している。 これは完全に信頼できるものではない。

call_api(int prcnt, int drcnt, int mprcnt, int mdrcnt, 
	char *param, char *data, char **rparam, char **rdata);

この関数はclient.c内で定義されている。リモートAPIを呼び出すためにSMBトランザクションで 使われる。

特定のデータ構造は、コード文字を含むASCIIZ文字列を使って記述される。以下は コード文字である:

新しいモジュールシステムは以下の利点を有する:

Samba内のいくつかのサブシステムは、異なったバックエンドを使う。それらのバックエンドは、 Sambaに静的にリンクするか、プラグインとして提供されているかのどちらかである。 サブシステムは、モジュールそれ自身を登録する事を許可する関数をもっている。例えば、 passdbサブシステムでは以下の通り:

NTSTATUS smb_register_passdb(int version, const char *name, pdb_init_function init);

この関数は、モジュールそれ自身を登録するために初期化関数によって呼ばれる。

/* Static init functions */
#define static_init_pdb { pdb_mysql_init(); pdb_ldap_init(); pdb_smbpasswd_init(); pdb_tdbsam_init(); pdb_guest_init();}

各モジュールは初期化関数をもっている。Sambaに含まれるモジュールでは、 この名前は 'subsystem_backend_init' である。(決して組み込まれないが、モジュールとしてのみ提供される)外部モジュールでは、 この名前は常時init_module'である(モジュールがSambaに含まれる場合、 configureシステムは#define subsystem_backend_init() init_module()を追加する)。 これらの関数のプロトタイプは以下の通り:

NTSTATUS init_module(void);

この関数は1回またはそれ以上登録関数を呼び出すべきである。関数は 成功時にはNT_STATUS_OKか、NT_STATUS_UNSUCCESSFULか、失敗時に便利に使える nt error codeを返すべきである。

たとえばpdb_ldap_init()は以下を含む:

NTSTATUS pdb_ldap_init(void)
{
smb_register_passdb(PASSDB_INTERFACE_VERSION, "ldapsam", pdb_init_ldapsam);
smb_register_passdb(PASSDB_INTERFACE_VERSION, "ldapsam_nua", pdb_init_ldapsam_nua);
	return NT_STATUS_OK;
}

SMB_MODULE(subsystem_backend, object files, plugin name, subsystem name, static_action, shared_action)
SMB_SUBSYSTEM(subsystem,depfile)

この文書は、どのようにSamba3.0用の新しいRPC着脱可能なモジュール機能を使えるように するかについて説明している。このアーキテクチャは、メインのCVSブランチから分かれて 作業されることをRPCパイプについて許可しているSambaの維持管理性を向上させることを 付加する。RPMアーキテクチャはまた、サードパーティベンダに対して、プラグインを通して、 Sambaに対して機能を追加する事も認めている。

RPC呼び出しがsmbdに送られる時、smbdは、もしもその呼び出しを内部的に処理する方法が 無い場合、それを処理するための、librpc_<pipename>.so という名前の共有ライブラリをロードしようとする。例えば、LSA呼び出しは librpc_lsass.soによって処理される。これらの共有ライブラリは、 <sambaroot>/lib/rpc中に配置されるべきである。 smbdは次に共有ライブラリ内のinit_module関数を呼び出そうとする。詳細はモジュールの 章を参照のこと。

init_module関数内で、ライブラリはrpc_pipe_register_commands()を呼び出すべきである。 この関数は以下の引数を取る:

NTSTATUS rpc_pipe_register_commands(int version, const char *clnt, const char *srv,
                               const struct api_struct *cmds, int size);

どのようにこのライブラリを使うかについての小さな例については、 rpc_server/srv_reg.c と rpc_server/srv_reg_nt.cを参照。

Samba開発のほとんどが、POSIX互換なOSを使っている間、 NTファイルシステムの文法を適用する場合に、POSIXによって要求されるものよりも、 ファイルシステムに対してのもののほうがより明確である。Samba 2.2以降、すべての 操作に関連するファイルシステムは、NTFS文法を変換するために必要とされる追加の関数と、 POSIXの両方でモデル化された後の仮想ファイルシステム(VFS)のための、概要レイヤ を通して行われる。

この概要レイヤは、現在通常のPOSIXファイルシステムが持っているものよりもたくさんの機能を 提供している。それらすべてが使用している特定のファイルシステムに対して実装すべきであるという ことは要求されない。しかし、それらの機能が有効な時、SambaはCIFSクライアントに対して それを公告し、それらは、それらの機能に遭遇する時、更に多くの追加機能を期待する ことを予測するかもしれないという事を意味するWindowsクライアントの場合、とアプリケーション によって使われるかもしれない。これらには、実行時にVFSモジュールを動的にロードするための 基盤を提供することにより処理が出来ることとSambaのコアを変更なしに、この降雪を扱うことを 許可するための実際的な理由がある。 This abstraction layer now provides more features than a regular POSIX file system could fill in. It is not required that all of them should be implemented by your particular file system. However, when those features are available, Samba would advertize them to a CIFS client and they might be used by an application and in case of Windows client that might mean a client expects even more additional functionality when it encounters those features. There is a practical reason to allow handling of this snowfall without modifying the Samba core and it is fulfilled by providing an infrastructure to dynamically load VFS modules at run time.

各VFSモジュールは数多くのVFS動作を実装できる。それがそれを行う方法とは 無関係であり、たった2つの事が実際には重要である:特定の実装が他のモジュールの 実装と協調することを必要としているか否かかということと、モジュールが、それが動作中の 文脈で特有である追加情報を格納することを必要とするか否かということである。 複数のVFSモジュールは同じ時にロードでき、異なったパラメーターで同じVFSモジュールの、 いくつかのインスタンスをロードすることも可能である。

typedef enum _vfs_op_type {
	SMB_VFS_OP_NOOP = -1,

	...

	/* File operations */

	SMB_VFS_OP_OPEN,
	SMB_VFS_OP_CLOSE,
	SMB_VFS_OP_READ,
	SMB_VFS_OP_WRITE,
	SMB_VFS_OP_LSEEK,
	SMB_VFS_OP_SENDFILE,

	...

	SMB_VFS_OP_LAST
} vfs_op_type;

struct vfs_ops {
	struct vfs_fn_pointers {
		...
		
		/* File operations */
		
		int (*open)(struct vfs_handle_struct *handle,
			struct connection_struct *conn,
			const char *fname, int flags, mode_t mode);
		int (*close)(struct vfs_handle_struct *handle,
			struct files_struct *fsp, int fd);
		ssize_t (*read)(struct vfs_handle_struct *handle, 
			struct files_struct *fsp, int fd, void *data, size_t n);
		ssize_t (*write)(struct vfs_handle_struct *handle, 
			struct files_struct *fsp, int fd, 
			const void *data, size_t n);
		SMB_OFF_T (*lseek)(struct vfs_handle_struct *handle, 
			struct files_struct *fsp, int fd, 
			SMB_OFF_T offset, int whence);
		ssize_t (*sendfile)(struct vfs_handle_struct *handle, 
			int tofd, files_struct *fsp, int fromfd, 
			const DATA_BLOB *header, SMB_OFF_T offset, size_t count);

		...
	} ops;
	
	struct vfs_handles_pointers {
		...
		
		/* File operations */
		
		struct vfs_handle_struct *open;
		struct vfs_handle_struct *close;
		struct vfs_handle_struct *read;
		struct vfs_handle_struct *write;
		struct vfs_handle_struct *lseek;
		struct vfs_handle_struct *sendfile;
		
		...
	} handles;
};

...
	
/* File operations */
#define SMB_VFS_OPEN(conn, fname, flags, mode) \
	((conn)->vfs.ops.open((conn)->vfs.handles.open,\
	 (conn), (fname), (flags), (mode)))
#define SMB_VFS_CLOSE(fsp, fd) \
	((fsp)->conn->vfs.ops.close(\
	(fsp)->conn->vfs.handles.close, (fsp), (fd)))
#define SMB_VFS_READ(fsp, fd, data, n) \
	((fsp)->conn->vfs.ops.read(\
	(fsp)->conn->vfs.handles.read,\
	 (fsp), (fd), (data), (n)))
#define SMB_VFS_WRITE(fsp, fd, data, n) \
	((fsp)->conn->vfs.ops.write(\
	(fsp)->conn->vfs.handles.write,\
	 (fsp), (fd), (data), (n)))
#define SMB_VFS_LSEEK(fsp, fd, offset, whence) \
	((fsp)->conn->vfs.ops.lseek(\
	(fsp)->conn->vfs.handles.lseek,\
	 (fsp), (fd), (offset), (whence)))
#define SMB_VFS_SENDFILE(tofd, fsp, fromfd, header, offset, count) \
	((fsp)->conn->vfs.ops.sendfile(\
	(fsp)->conn->vfs.handles.sendfile,\
	 (tofd), (fsp), (fromfd), (header), (offset), (count)))

...

typedef enum _vfs_op_layer {
	SMB_VFS_LAYER_NOOP = -1,	/* - For using in VFS module to indicate end of array */
					/*   of operations description */
	SMB_VFS_LAYER_OPAQUE = 0,	/* - Final level, does not call anything beyond itself */
	SMB_VFS_LAYER_TRANSPARENT,	/* - Normal operation, calls underlying layer after */
					/*   possibly changing passed data */
	SMB_VFS_LAYER_LOGGER,		/* - Logs data, calls underlying layer, logging may not */
					/*   use Samba VFS */
	SMB_VFS_LAYER_SPLITTER,		/* - Splits operation, calls underlying layer _and_ own facility, */
					/*   then combines result */
	SMB_VFS_LAYER_SCANNER		/* - Checks data and possibly initiates additional */
					/*   file activity like logging to files _inside_ samba VFS */
} vfs_op_layer;

基本的に、ファイルは行単位で処理される。構文解析ルーチン(param.c)によって認識される 4つのタイプの行がある。

最初の2つはもっぱら構文解釈ルーチンによって無視される。残りの2つのタイプは、 以下を解釈する。

パラメーターローダー(loadparm.c)にトークンのみが渡される。パラメーター名と値はそれぞれを 等号('=')で分離される。

	param name = parameter value string \
	with line continuation.

    param name = parameter value string     with line continuation.

	param name = parameter value string \
    \
    with line continuation.

param name = parameter value string         with line continuation.

	param name = parameter value string \
	; comment \
    with a comment.

param name = parameter value string     ; comment     with a comment.

	[ section   name ] garbage \
    param  name  = value

	[section name]
    param name = value

smb.confファイルの文法は以下のようになる:

  <file>            :==  { <section> } EOF
  <section>         :==  <section header> { <parameter line> }
  <section header>  :==  '[' NAME ']'
  <parameter line>  :==  NAME '=' VALUE NL

基本的に、これの意味は以下のようになる

現在のSambaのコードベースは、NetBIOS名の登録と解決のための共通の名前空間を共有する、 グループになっているWINSサーバーを使う能力を持っている。正式なパラメーターの文法は 以下の通り。

	WINS_SERVER_PARAM 	= SERVER [ SEPARATOR SERVER_LIST ]
	WINS_SERVER_PARAM 	= "wins server"
	SERVER 			= ADDR[:TAG]
	ADDR 			= ip_addr | fqdn
	TAG 			= string
	SEPARATOR		= comma | \s+
	SERVER_LIST		= SERVER [ SEPARATOR SERVER_LIST ]

有効なwinsサーバーの設定例は以下の通り。

[global]
	wins server = 192.168.1.2 192.168.1.3

リスト中のSERVER用にTAGが定義されていないイベント中では、smbdは"*"という、 既定値のタグを割り当てる。TAGはNetBIOS名前空間を一緒に共有するサーバーをグループにする のに使われる。起動時から、nmbdはNetBIOS名の値を、各タグづけられたグループ中に1つのサーバーを 登録しようと試みる。

WINSサーバーを一緒にグループ化するためのタグの使い方の例は以下にある。タグ中の インタフェース名の使用は、単に慣習的なものによるもので、技術的な要求ではないことに 注意。

[global]
	wins server = 192.168.1.2:eth0 192.168.1.3:eth0 192.168.2.2:eth1

この設定を使い、nmbd はサーバーのNetBIOS名を、各グループ中で1つのWINSサーバーに 登録しようと試みる。"eth0"グループは2つのサーバーを持つという理由で、 2番目のサーバーは登録(あるいは名前解決)要求が、そのグループの最初のサーバーに対して タイムアウトになった時にのみ使われる。

NetBIOS名前解決は名前登録と同じようなパターンで処理を行う。WINS経由でNetBIOS名の 解決を行うとき、smbdと他のSambaプログラムは、どこからか最短で肯定応答が返るまでか、 名前問い合わせ要求に対してすべてのタグされたグループのサーバーから否定応答が返るまで、 タグされたグループ中の、単一のWINSサーバーに問い合わせを試みる。もしも、特定のWINS サーバーに対して、問い合わせのタイムアウトが発生した場合、そのサーバーは、その先また タイムアウトが起きないようにダウンしているとマークされ、WINSグループ内の次のサーバーに 接続する。一度停止とマークされると、Sambaは10分間は名前登録/解決の問い合わせを、 そのサーバーに対して行おうとはしない。

Samba用の、LanManager と Windows NT互換のパスワード暗号化は、 LanManager または Windows NT サーバーと正確に同じ方法で、ユーザーの接続を 検証することが出来るようになっている。

この文書は、どのようにSMB パスワードの暗号化アルゴリズムが動作し、 それを使うことを選択する場合に、何が問題化について記述している。この文書を 特に、セキュリティと"PROS and CONS"節を注意深く読むべきである。

LanManagerの暗号化はUNIパスワードの暗号化と若干似ている。サーバーは、 ユーザーのパスワードをハッシュ化した値を含むファイルを使う。これは、ユーザーからの 平文パスワートを得て、それを大文字化し、14文字で打ち切るか、NULL文字を14文字に なるまで埋めることのどちらかを行って作成する。この14バイトの値は、'特別な' 8バイトの値に暗号化されるため、2つの56ビットDESキーとして使われ、サーバーと クライアントによって保存される16バイトの値に整形される。これは、 "ハッシュ化されたパスワード"として知られる。

Windows NTの暗号化は非常に高品質のメカニズムで、ユニコード版の、 ユーザーのパスワード上で、MD4ハッシュを行うことから成り立っている。これはまた、 可逆変換不可能な16バイトハッシュ値である。

クライアント(LanManager, Windows for WorkGroups, Windows 95 か Windows NT)がSambaドライブ(かSambaリソース)をマウントしようとした時、 最初に接続を要求し、クライアントとサーバーが使うプロトコルを調整する。 この要求のリプライ中で、Sambaサーバーは8バイトのランダム値を生成し添付する。 これは、"チャレンジ"と呼ばれ、リプライが返ってくることに備えてSambaサーバー中に 保存される。チャレンジはすべてのクライアント接続毎に異なる。

クライアントは次にハッシュ化されたパスワード(上記で説明されている 16バイト値)を使い、5つのNULL文字を追加し、3つの56ビットDESキーとし、 それは、おのおのチャレンジの8バイト値を暗号化するのに使われ、"レスポンス" と呼ばれる24バイトの値に整形する。

SMB呼び出しSMBsessionsetupX(ユーザーレベルセキュリティが選択された場合)中か、 STBtconX呼び出し(共有レベルセキュリティが選択された場合)中で、24バイトの レスポンスはクライアントによってSambaサーバーに戻される。Windows NTプロトコル レベル用に、上記の計算が、ユーザーのパスワードのハッシュ両方ととレスポンス両方に 対して行われ、2つの24バイト値がSMB呼び出しに対して戻される。

Sambaサーバーは次に上記の計算を、サーバー内に保存されている16バイトの ハッシュ化されたパスワード(後述するsmbpasswdから読んで)、 ネゴシエートプロトコルの返答から得たチャレンジ値を使って再度行う。それは 次に、計算した24バイトの値がクライアントから返されたものと一致するかを 確認する。

もしも、それらの値が性格に一致するならば、クライアントが正しいパスワード (か、16バイトのハッシュ化された値 - 以下のセキュリティに関する注意を参照) を使っていて、その結果アクセスは許可される。もしもそうでない場合、 クライアントは正しいパスワードを使っておらず、アクセスは拒否される。

Sambaサーバーはユーザーの平文パスワードを受け取ったり、格納することは 決してないことに注意。それに由来する16バイトのハッシュ値のみである。また、 平文パスワードまたは16バイトのハッシュ値はネットワーク上を決して流れない。 そのため、セキュリティは向上する。

Sambaが上記のプロトコルに参加するために、それがユーザー名と等価ならば、 16バイトのハッシュ値を検索できる必要がある。残念ながら、UNIXパスワードの 値は1方向ハッシュ関数による値なので(すなわち、UNIXのハッシュとして与えられた、 ユーザーの平文パスワードを検索することは不可能である)、この16バイト値を含む 分離されたパスワードファイルを用意しなければならない。2つのパスワードファイルに 起因する、同期ずれ問題を最小限にするために、UNIXの /etc/passwd と smbpasswd、 ユーティリティmksmbpasswd.shがUNIXの /etc/passwdからsmbpasswdファイルを生成するために 提供されている。

使用している/etc/passwdファイルからsmbpasswd ファイルを生成するために、以下のコマンドを使用する:

$ cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd

もしも、NISを使っているシステム上ならば、以下を使用する

$ ypcat passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd

mksmbpasswd.shプログラムは、Sambaソース ディレクトリ中にある。既定値では、smbpasswdファイルは下記にある:

/usr/local/samba/private/smbpasswd

/usr/local/samba/private/ ディレクトリの 所有者は、rootに設定すべきであり、それのアクセス許可設定は、0500 (chmod 500 /usr/local/samba/private)に設定すべきである。

同じように、privateディレクトリ内のsmbpasswdファイルはrootが所有 すべきであり、それのアクセス許可設定は、0600 (chmod 600 smbpasswd)にすべきである。

smbpasswdファイルの形式は以下の通り(ここでは行を折り返している。 smbpasswdファイル内では、1つのエントリ毎に1行となっている):

username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
	[Account type]:LCT-<last-change-time>:Long name
	

Although only the username, uid, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, [Account type]と last-change-timeセクションのみが重要であり、Sambaソースコード 内ではそれらのみが参照される。

XXXセクション中に、32の'X'文字の間に2つの':'文字があることが、 特に重要で、smbpasswdとSambaのコードは、 ':'の文字の間に32文字がない任意のエントリについては認証に失敗する。 最初のXXXセクションはLanman passwordハッシュで、2番目はWindows NT 用である。

passwordファイルが生成された時、すべてのユーザーは32個の'X'文字を含む パスワードエントリを持つ。既定値で、これはこのユーザーに対して、何らの アクセスも許可しない。ユーザーがパスワードを設定すると、'X'文字は32バイトの ASCII16進数値(0-9,A-F)に変わる。これは、ユーザーのパスワードの、 16バイトハッシュ値を表現したものである。

(推奨しないが)ユーザーがパスワードを持たないようにするためには、viを 使ってこのファイルを編集し、最初の11文字をASCII文字列 "NO PASSWORD"(引用符は勘定に入れない)に置き換える。

たとえば、ユーザーbobのパスワードをなくすには、彼のパスワードファイルの エントリを以下のようにする:

bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
	[U          ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
	

もしも、自分自身でsmbpasswdコマンドを使ってパスワードを設定することを認めて いるならば、(推奨しないが)ユーザーがパスワードを再設定する時に、以前の パスワードを入力しなくてすむよう、初期値としてユーザーに NO PASSWORD を設定しても よいだろう。これを行うためには、smbpasswdプログラムは そのユーザーがパスワードなしで動くために、smbdデーモンに 接続できる必要がある。これを行うには以下のような設定を

null passwords = yes

smb.confファイルの[global]セクションに(これが、なぜ上記の記述が 推奨されないかの理由である)記述する。出来れば、最初に各ユーザーの初期パスワードを 設定すれば、使用するサーバー上でこれを有効にしなくてすむ。

注意 : このファイルはとても注意深く保護すべきである。 誰でもがこのファイルにアクセスできると言うことは、(プロトコルについて 十分な知識がなくても)使用するSMBサーバーへのアクセス権を得ることが出来ることに なるからである。ファイルはそのため通常のUNIX/etc/passwd ファイルよりもより機密性が高い。

この文書の目的は、いくつかのSambaの印刷機能についての概要を提供することと、 Windowsクライアントの印刷の特定の機能についての説明を行うことである。

Sambaは7つの機能に対する関数ポインターテーブルを使う。関数のプロトタイプは printing.h中で記述されるprintif構造体中で 定義されている。

現在、2つの印刷バックエンドの実装のみが定義されている。

Sambaはパフォーマンス向上のために、"lpq command"からの出力を定期的にキャッシュする 機能を提供する。このキャッシュ時間は秒単位で設定可能である。明らかに、キャッシュ時間が より長いと、それだけsmbdはlpqへのコピーを行う回数が減る。しかし、クライアントに見せる 印刷キューの内容の正確さは、減少するだろう。

現在オープンしている印刷キューTDBのリストは、tdb_print_db structuresのリストを 調べることによって見つけることが出来る(printing.c中のprint_db_head参照)。1つのキュー TDBはラッパー関数printing.c:get_print_db_byname()を使うことによってオープンされる。 関数は、すべての有効なファイルディスクリプタを使い果たしてしまうことから、大きな 印刷サーバーを防ぐための効果がある、MAX_PRINT_DBS_OPENよりも数多く開かない事をsmbdに 行わせる。もしもキューTDBのオープン数がMAX_PRINT_DBS_OPENの制限を超過した場合、 smbdはオープンTDBのリストを管理するためMRU(most recently used)アルゴリズムを使う。

印刷ジョブを印刷キューTDB中に投入できるための2つの方法がある。最初のものはTDB中に ジョブ情報を直接挿入するWindowsクライアントからジョブを投入する方法である。2番目の 方法は存在している"lpq command"を実行することで、印刷ジョブをピックアップする方法である。

/* included from printing.h */
struct printjob {
	pid_t pid; /* which process launched the job */
	int sysjob; /* the system (lp) job number */
	int fd; /* file descriptor of open file if open */
	time_t starttime; /* when the job started spooling */
	int status; /* the status of this job */
	size_t size; /* the size of the job so far */
	int page_count;	/* then number of pages so far */
	BOOL spooled; /* has it been sent to the spooler yet? */
	BOOL smbjob; /* set if the job is a SMB job */
	fstring filename; /* the filename used to spool the file */
	fstring jobname; /* the job name given to us by the client */
	fstring user; /* the user who started the job */
	fstring queuename; /* service number of printer for this job */
	NT_DEVICEMODE *nt_devmode;
};

printjob 構造体の現在の状態には、"lpq command"から戻されるUNIXジョブIDと、 Windows ジョブID(PRINT_MAX_JOBIDによって32ビットごとに区切られる) のためのフィールドが含まれている。印刷ジョブが、キューTDB中に存在するジョブに 一致しない"lpq command"によって戻された場合、上記の32ビットジョブID <*vance doesn't know what word is missing here*>がlpqによって報告される ID用にUNIX_JOB_STARTを追加して生成される。

32ビットWindowsジョブIDを16ビットlanman印刷ジョブIDに一致させるために、smbdは 古いlanmanクライアントのために、前半部分の適切な数値を一致させるためのメモリTDBを使う。

印刷キューを更新する時、smbdは以下の手順を実行する (print.c:print_queue_update()を参照):

これは、Windowsクライアントに返されるTDBの内容であり、"lpq command"からの実際の一覧とは 違うことに注意。

printjob構造体の一部として格納されるNT_DEVICEMODEは、印刷ジョブに関連づけられる 非標準のDeviceModeへのポインターを格納するのに使われる。ポインターは、クライアントが OpenPrinterEx()呼び出し中でDevice Modeを含める時にnull以外になり、その同じハンドルで 印刷のために引き続いてジョブを投入する。もしもクライアントがOpenPrinterEx()要求に 対してDevice Modeを含めないのであれば、nt_devmodeフィールドはNULLであり、ジョブは 既定値で、それに関連づけられるプリンターのデバイスモードを持つ。

非標準のDevice Modeのみが印刷キューTDB中にプリントジョブと一緒に格納される。それ以外は、 Device Modeは、クライアントがGetJob(level == 2)要求を発行した時、プリンターオブジェクト から得られたものである。

[後日作成]

Windows NT+クライアントで動作している場合、プリンターサーバーに対してRPCを使って、 クライアントに、特定のプリンターと印刷ジョブ属性の、非同期な変更通知イベント を送ることが出来る。これは、クライアントが指定したプリンターに対して新しいジョブが キューに追加されたことか、プリンターのドライバーが変更されたかを知る必要がある時に 便利である。これは、プリンターオブジェクトのなめの新しいChangeID上をベースとした キャッシュ更新とは完全に無関係に行われることに注意。

変更通知を実装するために使われる基本的なRPCの使用範囲は以下の通り

1つの追加RPCがサーバーに対して有効であるが、それはWindows spoolerサービスでは決して 使われない:

それらすべてのRFC用のopnumはinclude/rpc_spoolss.hで定義されている。

Windows NT印刷サーバーはクライアントに印刷通知イベントを送る変わった方法を使っている。 新しい変更通知ハンドルの登録プロセスは、以下のようになる。'C'はクライアントで、 'S'はサーバーである。すべてのエラー状態は省略されている。

C:	標準OpenPrinterEx()呼び出しを経由して、プリンターかプリンターサーバーへの
	ハンドルを得る。
S:	オブジェクトへの有効なハンドルを返す。

C:	(a)モニターへの変更イベントのための1まとまりのフラグか、(b)モニターへの
	イベント情報を含むPRINTER_NOTIFY_OPTIONS構造体のどちらかと共に、
	以前に入手したハンドルと共にRFFPCN要求を送る。Windows spoolerは
	(b)の使用のみを観察している。
S:	<*他の間違った単語*>はクライアントに対する新しいTCPセッションを開き
	(そのため、すべての印刷クライアントはCIFSサーバーであるように要求する)、
	クライアントに対して、ReplyOpenPrinter()要求を送信する。
C:	クライアントは、イベント通知メッセージを送るために使われる事が出来る、
	プリンターハンドルを返す。
S:	サーバーはRFFPCN要求に対して成功を返す。

C:	Windows spoolerは、すべての、モニターしている属性の現在値を取得するために、
	RFNPCNを使うRFFPCNをフォローする。
S:	サーバーはSPOOL_NOTIFY_INFO_DATA構造体(SPOOL_NOTIFY_INFO構造体を含む)を
	返す。

C:	もしも、変更通知ハンドルがFCPCN要求経由でクライアントにより常に開放されるならば、
	サーバーは最初にクライアントに対してReplyClosePrinter()要求を返す。しかし、
	クライアントからのこの性質の要求は、しばしば以前の通知イベントがサーバーによって、
	正しく整理されなかったか、データの一部分が間違っていたかを示すものである。
S:	サーバーは内部の変更通知ハンドル(POLICY_HND)をクローズし、そのプリンターかジョブに
	対する変更通知イベントは、その後クライアントに送らないようになる。

Sambaによってサポートされている、現在の通知イベントのリストは、srv_spoolss_nt.c中の 内部テーブルを捜すことで見つけることが出来る。

モニターされているイベントが発生した時、smbdは変更についてそれ自身にメッセージを送る。 送信されるイベントのリストは、目セージの送信によって、TDBの利用状態が高負荷になる ことを防ぐためにsmbdプロセスによってキューされ、内部メッセージは、smbdがアイドル 状態の時に(printing/notify.cとsend_spoolss_notify2_msg()関数と print_notify_send_messages()関数を参照)送信される。

変更状態を、接続されているクライアントに送るかどうかの決定は、実際に通知を送る ルーチンによって行われる(srv_spoolss_nt.c:recieve_notify2_message()を参照)。

複数のプリンターの複数の変更の一覧を受け取ることが可能という理由で、通知イベントは プリンター名の区分けによって分離される必要がある。これにより、ReplyOpenPrinter()経由で 得られるプリンターハンドルによる、単一のRPCで、複数の変更イベントを送れるようになる。

実際の変更通知はRRPCN要求RPCを使って実行される。このパケットは以下を含む

SPOOL_NOTIFY_INFOは以下を含む:

SPOOL_NOTIFY_INFO_DATAは以下を含む:

是非是非source/VERSION中にベンダバージョンサフィックスと番号を 設定し、使用するパッケージのバージョニングを含めるために source/script/mkvesion.shを呼び出してほしい。ベンダバージョンを 作成するための関数を設定することがそこでは出来る。これにより、個別に構築したSambaシステム (しばしばパッチを当てたパッケージ)から標準のSambaシステムを区別するのがとても容易になる。 例えば、良いバージョンの例は以下の通り:

Version 2.999+3.0.alpha21-5 for Debian

Samba3 はプラグインとしてSambaの一部を構築することをサポートしている。これは、たとえば、 ldapまたはmysqlサポートを別パッケージにすることが可能となり、その結果、通常のSamba パッケージがLDAPやmysqlに依存しないようにすることが出来る。Sambaの多くの部分をプラグイン として構築するためには、以下のように行う:

The option --with-shared-modulesは、たとえばidmap_XXX and vfs_XXX のような特定のモジュールをサポートするために維持されている。例えば、 --with-shared-modules=idmap_adである。公式のリリース中で サポートしないように、configureコマンドにこのパラメーターを使用する。

./configure --with-shared-modules=rpc,vfs,auth,pdb,charset