smbd [-D] [-a] [-o] [-P] [-h] [-V] [-d debuglevel] [-l log file] [-p port number] [-O socket options] [-s configuration file]
このプログラムは Samba スイートの一部である。
smbd は Windows クライアントにファイル共有と印刷サービスを提供する サーバデーモンである。 サーバは SMB (または CIFS) プロトコルを使用するクライアントに ファイル・スペースと印刷サービスを提供する。 サーバは 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 を終了して再起動するまで構成ファ イルの変更は反映されない。
既定ではサーバはデーモンとして動作しない。
このパラメータが指定されないときの既定値はゼロである。
値が大きくなる程、 サーバの動作に関するより詳細な情報がログ・ファイルに記録される。 レベル 0 では、重大なエラーや深刻な警告のみ記録される。 レベル 1 は日々動作させるには最適なレベルである \- これは動作記録についての概略レベルの情報を生成する。
1 より大きいレベルはかなりの量の記録データを生成するため、 問題を調査するときのみ使用されるべきである。 3 より上のレベルは開発者によってのみ使用されるように設計されており、 そのほどんどが暗号のような膨大な量の記録データを生成する。
このパラメータは、smb.conf(5) ファイルの log level パラメータの値を上書きすることに注意。
この数字は、クライアント・ソフトウェアからサーバへの接続を確立するときに 使用されるポート番号である。 SMB over TCP の標準的な(well-knownな)ポート番号は 139 であり、 それ故にこれが既定値である。 あなたが root ではないふつうのユーザでサーバを動作させたいならば、 多くのシステムでは 1024 より大きいポート番号を使わなければならない。\- あなたがこの状況にいるかどうかは、あなたのシステムの管理者に尋ねるとよい。
たいていのクライアントからサーバを利用できるようにしたくても ポートを 139 以外に構成しなければならないときは、 ポート 139 にポート・リダイレクト・サービスが必要になる。 詳しくは rfc1002.txt の 4.3.5 節に概略が述べられている。
このパラメータは、上記の状況を除いては通常指定しない。
/etc/inetd.conf
サーバを inetd メタ・デーモンによって動作させるには、 このファイルにメタ・デーモン用の適当な始動情報を含める必要がある。 以下の「インストール」の節を参照のこと。
/etc/rc
(あるいは、あなたのシステムが使用するあらゆる初期化スクリプト)
システム起動時にデーモンとしてサーバを動作させるなら、 このファイルにサーバのための適切な起動順序を含める必要がある。 以下の「インストール」の節を参照のこと。
/etc/services
inetd メタ・デーモンを介してサーバを動作させるなら、 このファイルにサービス・ポート(例: 139)と プロトコル・タイプ(例: tcp)に対する サービス名(例: netbios-ssn)のマッピングを含める必要がある。 以下の「インストール」の節を参照のこと。
/usr/local/samba/lib/smb.conf
このファイルはサーバの設定ファイルである smb.conf の デフォルトの位置である。 その他、システムがこのファイルをインストールしそうな場所としては、 /usr/samba/lib/smb.conf や /etc/smb.conf がある。
このファイルにはサーバがクライアントから利用できるようにする全てのサービスを 記述する。 さらなる情報は smb.conf (5) を参照のこと。
いくつかのシステム上において、smbd は setuid() 呼び出しの後に uid を root に戻すことができない。 そのようなシステムは「落とし戸(trapdoor)」uid システムと呼ばれる。 そのようなシステムの場合、異なるユーザとして (PC のような)クライアントから同時に接続を行うことができない。 二人目のユーザ接続の試みは、「アクセス拒否」または類似の結果となる。
PRINTER プリント・サービスでプリンタの名前が指定されていないとき、 多くのシステムでは使用するプリンタ名として、 この変数の値が(もしくは変数が定義されていないなら「lp」が)利用される。 しかしながらこれはサーバーの特性であるという訳ではない。
サーバとそのサポート・ファイルをどこに置くべきかは、 各システム管理者が判断すべき問題である。 従って、以下は単なる提案である。
サーバ・ソフトウェアは、すべての人に読み出し可能で root によってのみ 書き込み可能なディレクトリ /usr/local/samba 以下にインストールすることを推奨する。 サーバ・プログラム自身は、サーバを自ら動作させたいと望むユーザすべてに よって実行可能にしなくてはならない(もちろん起動したユーザ権限で動作する)。
サーバは setuid するべきではない。 あるシステム上では、smbd を空のグループに setgid することが有効な場合がある。 これは、あるシステムでは、ユーザ権限で動作するデーモン・プロセスが デバッガによってアタッチされてしまうという セキュリティー・ホールが存在するためである。 smbd のファイルを空のグループに setgid することによって、 このホールが利用されるのを防ぐことができるかも知れない。 このセキュリティ・ホールおよび提案されている対策は、 この文書執筆時において古い (2.0 以前のカーネルの) Linux にのみ確認されている。 いまのところ Linux 以外のシステムのテストでは この問題は発生しないことが確認されており、 このホールは Linux にのみ存在する可能性がある。
サーバのログファイルは、 ログファイルにセキュリティ上問題がある情報を含むことがあるため、 root によってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。
構成ファイルは、 root によってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。 これは、サーバによって提供されるサービスのセキュリティを設定する設定ファ イルを含めためである。 場合によっては、構成ファイルは全員に読み出し可能にすることができるが、 サーバを正しく動作させる上で必要なことではないし、推奨されることでもない。 サンプルの構成ファイル「smb.conf.sample」がサーバのソースとともに配布されている \- これを「smb.conf」にリネームし、あなたの必要を満たすように変更しても良い。
これ以降の記述では、パスとして以下を仮定している:
サーバはユーザによって、または起動時にデーモンとして起動されるか、 もしくは inetd のようなメタ・デーモンからリクエストによって起動される。 デーモンとして起動する場合、サーバは常に接続を待機している状態であるため セッションの開始はより高速になる。 メタ・デーモンから起動する場合、いくらかのメモリが節約され、 セキュリティの向上のために TCP-wrapper tcpd のようなユーティリティを 使用することができる。 ファイルサーバとして実務で利用するのであれば、smbd をデーモンとし て動作させることを推奨する。
あなたの結論が出たなら、「サーバをデーモンとして起動する」または 「サーバをリクエストによって起動する」のどちらかを続けて読みなさい。
サーバをコマンドラインからデーモンとして起動するには、 単純にコマンドラインに -D オプションを付けなさい。 コマンドラインの最後にアンパーサンド '&' を置く必要はない。 -D オプションはサーバ自身に tty からの分離をさせる。
どんなユーザでもサーバをデーモンとして起動できる (もちろん、実行権限が許可されている場合に限る)。 これはテストを行う目的に便利であるし、 ftp のように、応急的に用いる場合もも有用であろう。 しかしこの場合の起動では、サーバは起動したユーザの特権を持つだけになる。
マシンの起動時にいつでもサーバをデーモンとして起動し、 複数のクライアントにサービスを提供できるように root として起動するには、 システムの起動ファイルを修正する必要がある。 どこか適切なところ(たとえば /etc/rc)に、ポート番号、ログファイルの場所、 構成ファイルの場所そしてデバッグ・レベルを望みのものにして、 以下の行を挿入しなさい:
/usr/local/samba/bin/smbd -D -l /var/adm/smblogs/log -s /usr/local/samba/lib/smb.conf
(上記の行は初期化スクリプト中で単一の行になるようにしなければならない。 あなたの端末の特質によっては、 このマニュアルではそのように見えないかもしれない。 上記が一行より多く見えるなら、すべての改行あるいはインデントは 単一のスペースまたは TAB 文字として扱ってください。)
コンパイル時に用いられたオプションがシステムに適切なものであれば、 -D 以外の全てのパラメータは省略できる。 上記の「オプション」節を参照のこと。
あなたのシステムが inetd のようなメタ・デーモンを使用しているなら、 プロセスが smbd サーバに接続を試みた時点で smbd サーバを起動するように設定できる。 これにはホスト・マシンの起動ファイルにいくつかの変更を必要とする。 あなたが root としてではなく、ふつうのユーザとして実験をしているなら、 システムファイルを修正するためにシステム管理者の協力が必要である。
おそらく、smbd と同時に NetBIOS ネームサーバである nmbd の設定も行ないたいであろう。 こちらは nmbd (8)のマニュアルページに 記述されている。
はじめに、ポートがファイル /etc/services
に設定されていることを
確認すること。
どのポートも使用できる場合であっても、可能な限り、
well-known ポートである 139 を使用すべきである。
以下と同じような行が /etc/services
にあることを確認すること:
netbios-ssn 139/tcp
NIS/YP ユーザへの注意 \- ローカルの /etc/services
ファイルを変更する
代わりに、NIS の service マップを再構築する必要があるだろう。
次に、ファイル /etc/inetd.conf に適当な行を置く(inetd 以外のメタ・デーモンを使っていて好ましくない行為なら、それ自身の該当する場所に置く)。 この行の最初の項目は、/etc/services のサービス名に一致することに注意して欲しい。 システムに合わせて次の行を適当な値にして使いなさい( .BR inetd (8)を参照):
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd -d1 -l/var/adm/smblogs/log -s/usr/local/samba/lib/smb.conf
(上記の行は /etc/inetd.conf
中で単一の行になるようにしなければならない。
あなたの端末の特質によっては、
このマニュアルではそのように見えないかもしれない。
上記が一行より多く見えるなら、すべての改行あるいはインデントは
単一のスペースまたは TAB 文字として扱うこと。)
標準でないポート番号を使用している場合でも、 ここにポート番号を指定する必要はないことに注意。
最後に、適当なサービスを提供するように構成ファイルを編集する。 手始めに、以下の二つのサービスが必要とするすべてのものであろう:
[homes] writeable = yes [printers] writeable = no printable = yes path = /tmp public = yes
これは、ホームディレクトリへの接続と、ホストでサポートされている (ユーザの権利を許可している)あらゆるプリンタへの印刷を認める。
サーバをデーモンとして起動するなら、先へ進む前にサーバを起動すること。 メタ・デーモンを使用するなら、システムを再起動するか メタ・デーモンを止めて再起動しなさい。 inetd のいくつかのバージョンは、HUP シグナルを受け取ると inetd の構成テーブルを再読み込みするだろう。
マシンの名前が「fred」で、あなたの名前が「mary」ならば、 サービス「\e\efred\emary」に接続できるようになるだろう。
サーバを正確にテスト・実験をするために、smbclient プログラム( smbclient (1)を参照)を使用することを勧める。 また、Samba をインストールした中の docs/ディレクトリにある DIAGNOSIS.txt に概要が記述されたステップを追って実行してみることも勧める。
このマニュアルページは、Samba スイートのバージョン 2.0 用のものである。
サーバによって出力されたほとんどの診断は 、指定されたログファイルに記録される。 ログファイルの名前はコンパイル時に指定されるが、 コマンドラインで変更することもできる。
利用できる診断の数と性質は、サーバで使用されるデバッグ・レベルに依存する。 もし問題を抱えているなら、 デバッグ・レベルを 3 に設定してログファイルに目を通すこと。
ほとんどのメッセージは充分に自明であろう。 あいにく、 このマニュアルページ作成時には あまりにもさまざまな診断メッセージが存在しているため、 診断メッセージをすべて記述することを保証できない。 そのような場合にもっともよい方法は、ソースコードを検索 (grep) することであり、 着目している診断メッセージを引き起こした条件を探すことである。
smbd に SIGHUP を送ることで、smb.conf の内容を短時間の内に再読み込みさ せることができる。
smbd のプロセスをシャットダウンさせるのに、最後の手段として以外には SIGKILL (\-9)は使わ ないことを推奨する。 共有メモリのエリアが不整合なままになってしまうことがあるためである。 smbd を安全に終了させる方法は、SIGTERM (\-15) を送って、 smnd 自身が終了するのを待つことである。
smbd のデバッグ・ログ・レベルを
SIGUSR1 を送る kill -USR1 <nmbd-pid>
ことにより上げたり、
SIGUSR2 を送る kill -USR2 <nmbd-pid>
ことにより下げたりすることができる。
これにより、低いログ・レベルで動作している間に発生する
一時的な問題を診断することができる。
デバッグ書き込みを送る smbd のシグナル・ハンドラは再入可能になっていない。 ゆえにシグナルを発行するときは、smbd が smb 待ちの状態になるまで待つ必 要がある。 select 呼び出しの前にシグナルのブロックを解除し、 呼び出しの後で再びブロックすればシグナル・ハンドラを安全にすることができるが、 これはパフォーマンスに影響するだろう。
hosts_access (5), inetd (8), nmbd (8), smb.conf (5), smbclient (1), testparm (1), testprns (1), and the Internet RFC's rfc1001.txt, rfc1002.txt. 加えて CIFS (公式な SMB)の仕様は以下の Web ページから入手できる: http://samba.org/cifs/
オリジナルの Samba ソフトウェアと関連するユーティリティは、 Andrew Tridgell samba@samba.org によって作られた。 Samba は現在 Linux カーネルが開発されているような方法での オープンソースプロジェクトである Samba Team によって開発されている。
オリジナルの Samba の マニュアルページは Karl Auer によって書かれた。 マニュアルページは YODL 形式(別の、優秀なオープンソースソフトウェアで、 ftp://ftp.icce.rug.nl/pub/unix/ にある)で変換され、Jeremy Allison によって Samba 2.0 リリースのために 更新された。 samba@samba.org.
貢献者の完全な一覧およびバグ報告、 コメント、その他を提出する方法の詳細は、 samba (7) を参照のこと。