smbd はほとんどの SMB サービスを提供できるサーバである。 サーバは SMB プロトコルを使用するクライアントにファイル・スペースと プリンタのサービスを提供する。 これは LanManager プロトコルと互換性があり、LanManager クライアントに サービスすることができる。クライアントには MSCLIENT 3.0 for DOS、 Windows for Workgroups、Windows 95、Windows NT、OS/2、 DAVE for Macintosh、smbfs for Linux などが含まれる。
サーバが提供できるサービスの広い説明は、それらサービスの属性を制御する 構成ファイルのマニュアルに与えられている( smb.conf (5) を参照)。 このマニュアルはサービスについて記述しないが、 サーバを動作させる上での管理の面に専念する。
このサーバを動作させることは重要なセキュリティーとの関係があること、 そして smb.conf (5) はインストールを進める前の必須の読み物であるとみなされることに注意してください。
セッションはクライアントに要求されるたびに作られる。 各クライアントは各セッションに対するサーバの複製を得る。 この複製はセッションの間、クライアントによるすべての接続を供給する。 クライアントのすべての接続が切断されると、そのクライアントに対するサーバの複製は終了する。
構成ファイルとそれに含まれるファイルが変更されると、 分ごとに自動的に再読込される。 サーバに SIGHUP を送ることにより再読み込みを強制することもできる。 構成ファイルの再読込は、既に確立されているサービスの接続には影響しない。 ユーザがサービスから切断するか、smbd を終了して再起動しなければならない。
既定ではサーバはデーモンとして動作しない。
-a
-d debuglevel
debuglevel は 0 から 10 の整数である。
このパラメータが指定されないときの既定値はゼロである。
より高い値では、サーバの作業に関するより多くの詳細がログ・ファイルに記録される。 レベル 0 では、重大なエラーや深刻な警告のみ記録される。 レベル 1 は毎日動作させるには最適なレベルである - これは作業の実行についての少ない量の情報を生成する。
1 より上のレベルはかなりの量の記録データを生成するため、 問題を調査するときのみ使用されるべきである。 3 より上のレベルは開発者によってのみ使用されるように設計されており、 そのほどんどが非常に謎めいている膨大な量の記録データを生成する。
-l log file
既定の基本となる名前はコンパイル時に指定される。
基本となる名前は実際の記録ファイルの名前を作り出すために使用される。 たとえば、名前として「log」が指定されると、以下のファイルがデータ記録に使用される:
log.in (入力処理のデータを含む)
log.out (出力処理のデータを含む)
生成されたログ・ファイルがサーバによって削除されることは決してない。
-O socket options
詳細は smb.conf (5) の socket options の節を参照。
port number は正の整数値である。
このパラメータが指定されていないときの既定値は 139 である。
この数字は、クライアント・ソフトウェアからサーバへの接続を確立するときに 使用されるポート番号である。
サーバの標準的な(有名な)ポート番号は 139 であり、それ故にこれが既定である。 あなたが root ではないふつうのユーザでサーバを動作させたいならば、 多くのシステムでは 1024 より大きいポート番号を使用することを要求するだろう - あなたがこの状況にいるかどうかは、あなたのシステムの管理者に尋ねるとよい。
たいていのクライアントからサーバを利用できるようにしたくても ポートを 139 以外に構成しなければならないときは、 ポート 139 にポート・リダイレクト・サービスが必要になる。 詳しくは rfc1002.txt の 4.3.5 節に概略が述べられている。
このパラメータは、上記の状況を除いては通常指定しない。
-s configuration file
指定されたファイルはサーバが必要とする構成の詳細を含んでいる。 このファイルの情報は、サーバが提供するすべてのサービスの記述はもちろん、 どの printcap ファイルを使用するかといったようなサーバの詳細な情報を含む。 さらなる情報は smb.conf (5) を参照。
/etc/rc
始動時にデーモンとしてサーバを動作させるなら、 このファイルにサーバ用の適切な始動順序を含める必要がある。 下の「インストール」の節を参照。
/etc/services
/usr/local/samba/lib/smb.conf
サーバ・ソフトウェアは、すべての人に読み出し可能で root によってのみ 書き込み可能なディレクトリ /usr/local/samba 階層の下にインストールすることを推奨する。 サーバ・プログラムはそれ自身、サーバを自ら動作させたい(この場合、もちろんユーザ権限で動作する) と望むユーザすべてによって実行可能にしなくてはならない。 サーバは setuid するべきではない。 いくつかのシステム上では、smbd をからのグループに setgid する価値があるだろう。 その理由は、いくつかのシステムでは、 ユーザになるデーモン・プロセスがデバッガによってアタッチできることによる セキュリティー・ホールを持っていることにある。 smbd ファイルをからのグループに setgid することによって、 このホールが利用されるのを防ぐことができる。 このセキュリティ・ホールと提案した修正は、この文書執筆時の Linux にのみ確認されている。
いまのところ Linux を除くほかのシステム上のテストでは免疫性があることが示されており、 このホールは Linux にのみ存在する可能性がある。
サーバのログファイルは、ログファイルに鋭敏な情報を入れるために、root に よってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。
構成ファイルは、サーバによって提供されるサービスのセキュリティを制御するために、 root によってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。 お望みなら構成ファイルは全員に読み出し可能にすることができるが、 サーバを正しく動作させる上で必要なことではないし、推奨されることでもない。 サンプルの構成ファイル「smb.conf.sample」がサーバのソースとともに配布されている - これを「smb.conf」にリネームし、あなたの必要を満たすように変更しても良い。
残りの注意事項は以下を仮定している:
smb.conf (構成ファイル) は /usr/local/samba/lib にインストールする
ログ・ファイルは /var/adm/smblogs に保存する
サーバはユーザによって、または起動時にデーモンとして起動されるか、 もしくは inetd のようなメタ・デーモンからリクエストによって起動される。 デーモンとして起動する場合、サーバは常に用意されているため セッションの開始はより高速になる。 メタ・デーモンから起動する場合、いくらかのメモリが節約されたり、 特別なセキュリティのために TCP-wrapper tcpd のようなユーティリティを 使用することができる。
あなたの結論が出たなら、「サーバをデーモンとして起動する」または「サーバをリクエストによって起動する」のどちらかを続けて読みなさい。
どんなユーザでもサーバをデーモンとして起動できる(もちろん、実行権限が許可されている)。 これはテストを行う目的に便利であるし、ftp のようななにかの一時的な代理としても有用であろう。 しかしこの場合の起動では、サーバは起動したユーザの特権を持つだけになる。
マシンの始動時にいつでもサーバをデーモンとして起動し、 複数のクライアントを扱えるように root として起動するのを確実にするには、 システムの始動ファイルを修正する必要がある。 どこか適切なところ(たとえば /etc/rc)に、ポート番号、ログファイルの場所、 構成ファイルの場所そしてデバッグ・レベルを望みのものにして、以下の行を挿入しなさい:
(上記の行は初期化スクリプト中で単一の行になるようにしなければならない。 あなたの端末の特質によっては、このマニュアルではそのように見えないかもしれない。 上記が一行より多く見えるなら、すべての改行あるいはインデントは 単一のスペースまたは TAB 文字として扱ってください。)
システムにとってコンパイル時のオプションの使用が適切ならば、 デバッグ・レベルの要求を除く、すべてのパラメータと -D は省略できる。 上記の「オプション」節を参照しなさい。
おそらく、 smbd と同時にネームサーバ nmbd の準備も望むだろう。 マニュアル nmbd (8) を参照。
はじめに、ポートがファイル /etc/services に構成されていることを確実にしなさい。 どのポートも使用できる場合であっても、可能なら、 よく知られている(well-known)ポート 139 を使用すべきである。
以下と同じような行が /etc/services にあることを確実にしなさい:
NIS/YP ユーザの注意 - ローカルの /etc/services ファイルを変更するのではなく、 NIS の service マップを再構築する必要があるだろう。
次に、ファイル /etc/inetd.conf に適当な行を置く(inetd 以外のメタ・デーモンを使っていて好ましくない行為なら、それ自身の該当する場所に置く)。 この行の最初の項目は、/etc/services のサービス名に一致することに注意して欲しい。 システムに合わせて次の行を適当な値にして使いなさい( inetd (8)を参照):
(上記の行は /etc/inetd.conf 中で単一の行になるようにしなければならない。 あなたの端末の特質によっては、このマニュアルではそのように見えないかもしれない。 上記が一行より多く見えるなら、すべての改行あるいはインデントは 単一のスペースまたは TAB 文字として扱ってください。)
標準でないポート番号を使用してる場合でも、 ここにポート番号を指定する必要はないことに注意。
最後に、適当なサービスを提供するように構成ファイルを編集する。 手始めに、以下の2つのサービスが必要とするすべてのものであろう:
[printers]
これは、ホームディレクトリへの接続と、ホストでサポートされている (ユーザの権利を許可している)あらゆるプリンタへの印刷を認める。
マシンの名前が「fred」で、あなたの名前が「mary」ならば、 サービス「\\fred\mary」に接続できるようになるだろう。
サーバを正確にテスト・実験をするために、smbclient プログラム( smbclient (1) を参照)を使用することを勧める。
サーバによって出されたほとんどの診断は、指定されたログファイルに記録される。 ログファイルの名前はコンパイル時に指定されるが、コマンドラインで変更することもできる。
利用できる診断の数と性質は、サーバで使用されるデバッグ・レベルに依存する。 もし問題を抱えているなら、デバッグ・レベルを 3 に設定してログファイルに目を通しなさい。
ほとんどのメッセージは充分に自明であろう。 あいにく、このマニュアル・ページ作成時にはソースコードがかなり流動しているので、 診断メッセージをすべて記述することはできない。 そのような場合にもっともよい方法は、ソースコードを検索 (grep) することであり、 着目している診断メッセージを引き起こした条件を探すことである。
デバッグ書き込みを送る smbd のシグナル・ハンドラは再入可能になっていない。 ゆえにそれらを発行する前に、 smbd が到達する SMB を待つ状態に入るまで待たなければならない。 select 呼び出しの前にシグナルのブロックを解除し、 呼び出しの後で再びブロックすればシグナル・ハンドラを安全にすることができるが、 これはパフォーマンスに影響するだろう。
貢献者の完全な一覧およびバグ報告、コメント、その他を提出する方法の詳細は、 smb.conf (5) を参照のこと。