SMBD(8)

名前

smbd - SMB (LanManager としても知られる) サービスをクライアントへ提供

形式

smbd [ -D ] [ -a ] [ -d debuglevel ] [ -l log file ] [ -p port number ] [ -O socket options ] [ -s configuration file ]

説明

このプログラムは Samba スイートの一部である。

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 を終了して再起動しなければならない。

オプション

-D

-a

-d debuglevel

-l log file

-O socket options

-p port number

-s configuration file

ファイル

/etc/inetd.conf

/etc/rc

/etc/services

/usr/local/samba/lib/smb.conf

制限

いくつかのシステム上において、 smbd は setuid() 呼び出しの後に uid を root に戻すことができない。 そのようなシステムは「落とし戸(trapdoor)」uid システムと呼ばれる。 そのようなシステムの場合、同時に2人の異なるユーザによる(PC のような)クライアント からの接続を行うことができない。 2番目のユーザ接続の試みは、「アクセス拒否」または類似の結果となる。

環境変数

PRINTER

インストール

サーバとそのサポート・ファイルをどこに置くべきかは、 各システム管理者が判断すべき問題である。 従って、以下は単なる提案である。

サーバ・ソフトウェアは、すべての人に読み出し可能で root によってのみ 書き込み可能なディレクトリ /usr/local/samba 階層の下にインストールすることを推奨する。 サーバ・プログラムはそれ自身、サーバを自ら動作させたい(この場合、もちろんユーザ権限で動作する) と望むユーザすべてによって実行可能にしなくてはならない。 サーバは setuid するべきではない。 いくつかのシステム上では、smbd をからのグループに setgid する価値があるだろう。 その理由は、いくつかのシステムでは、 ユーザになるデーモン・プロセスがデバッガによってアタッチできることによる セキュリティー・ホールを持っていることにある。 smbd ファイルをからのグループに setgid することによって、 このホールが利用されるのを防ぐことができる。 このセキュリティ・ホールと提案した修正は、この文書執筆時の Linux にのみ確認されている。

いまのところ Linux を除くほかのシステム上のテストでは免疫性があることが示されており、 このホールは Linux にのみ存在する可能性がある。

サーバのログファイルは、ログファイルに鋭敏な情報を入れるために、root に よってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。

構成ファイルは、サーバによって提供されるサービスのセキュリティを制御するために、 root によってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。 お望みなら構成ファイルは全員に読み出し可能にすることができるが、 サーバを正しく動作させる上で必要なことではないし、推奨されることでもない。 サンプルの構成ファイル「smb.conf.sample」がサーバのソースとともに配布されている - これを「smb.conf」にリネームし、あなたの必要を満たすように変更しても良い。

残りの注意事項は以下を仮定している:

サーバはユーザによって、または起動時にデーモンとして起動されるか、 もしくは inetd のようなメタ・デーモンからリクエストによって起動される。 デーモンとして起動する場合、サーバは常に用意されているため セッションの開始はより高速になる。 メタ・デーモンから起動する場合、いくらかのメモリが節約されたり、 特別なセキュリティのために TCP-wrapper tcpd のようなユーティリティを 使用することができる。

あなたの結論が出たなら、「サーバをデーモンとして起動する」または「サーバをリクエストによって起動する」のどちらかを続けて読みなさい。

サーバをデーモンとして起動する

サーバをコマンドラインからデーモンとして起動するには、単純にコマンドラインに -D オプションを付けなさい。 コマンドラインの最後にアンパーサンド '&' を置く必要はない。 -D オプションはサーバ自身に tty からの分離をさせる。

どんなユーザでもサーバをデーモンとして起動できる(もちろん、実行権限が許可されている)。 これはテストを行う目的に便利であるし、ftp のようななにかの一時的な代理としても有用であろう。 しかしこの場合の起動では、サーバは起動したユーザの特権を持つだけになる。

マシンの始動時にいつでもサーバをデーモンとして起動し、 複数のクライアントを扱えるように root として起動するのを確実にするには、 システムの始動ファイルを修正する必要がある。 どこか適切なところ(たとえば /etc/rc)に、ポート番号、ログファイルの場所、 構成ファイルの場所そしてデバッグ・レベルを望みのものにして、以下の行を挿入しなさい:

(上記の行は初期化スクリプト中で単一の行になるようにしなければならない。 あなたの端末の特質によっては、このマニュアルではそのように見えないかもしれない。 上記が一行より多く見えるなら、すべての改行あるいはインデントは 単一のスペースまたは TAB 文字として扱ってください。)

システムにとってコンパイル時のオプションの使用が適切ならば、 デバッグ・レベルの要求を除く、すべてのパラメータと -D は省略できる。 上記の「オプション」節を参照しなさい。

サーバをリクエストによって起動する

あなたのシステムが inetd のようなメタ・デーモンを使用するなら、 プロセスが smbd サーバに接続を試みるときに smbd サーバを始動するように手配できる。 これにはホスト・マシンの始動ファイルにいくつかの変更を必要とする。 あなたが root としてではなく、ふつうのユーザとして実験をしているなら、 システムファイルを修正するためにシステム管理者の助力が必要とする。

おそらく、 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つのサービスが必要とするすべてのものであろう:

これは、ホームディレクトリへの接続と、ホストでサポートされている (ユーザの権利を許可している)あらゆるプリンタへの印刷を認める。

インストールのテスト

サーバをデーモンとして起動するなら、進む前にサーバを実行しなさい。 メタ・デーモンを使用するなら、システムを再起動するか メタ・デーモンを止めて再起動しなさい。 inetd のいくつかのバージョンは、HUP シグナルを受け取ると inetd の構成テーブルを再読み込みするだろう。

マシンの名前が「fred」で、あなたの名前が「mary」ならば、 サービス「\\fred\mary」に接続できるようになるだろう。

サーバを正確にテスト・実験をするために、smbclient プログラム( smbclient (1) を参照)を使用することを勧める。

バージョン

このマニュアルは、(主に) Samba スイートのバージョン 1.9.00 と、 それに対応する最新のパッチのいくつかを追加したものに適用される。 これらの記録は、必然的にソフトウェアの開発より遅れることになるため、 あなたのバージョンのサーバに拡張があったり、パラメータの意味が異なったり、 マニュアルに記述されていないパラメータが存在する可能性がある。 これらの問題があったら、下記のアドレスに通知してほしい。

参照

hosts_access (5), inetd (8), nmbd (8), smb.conf (5), smbclient (1), testparm (1), testprns (1) rfc1001.txt rfc1002.txt

診断

[この節は工事中である]

サーバによって出されたほとんどの診断は、指定されたログファイルに記録される。 ログファイルの名前はコンパイル時に指定されるが、コマンドラインで変更することもできる。

利用できる診断の数と性質は、サーバで使用されるデバッグ・レベルに依存する。 もし問題を抱えているなら、デバッグ・レベルを 3 に設定してログファイルに目を通しなさい。

ほとんどのメッセージは充分に自明であろう。 あいにく、このマニュアル・ページ作成時にはソースコードがかなり流動しているので、 診断メッセージをすべて記述することはできない。 そのような場合にもっともよい方法は、ソースコードを検索 (grep) することであり、 着目している診断メッセージを引き起こした条件を探すことである。

シグナル

バージョン 1.9.18 とそれ以降では、smbd のデバッグ・ログ・レベルを SIGUSR1 を送る(kill -USR1 <nmbd-pid>)ことにより上げたり、 SIGUSR2 を送る(kill -USR2 <nmbd-pid>)ことにより下げたりすることができる。 これにより、低いログ・レベルで動作している間に発生する 一時的な問題を診断することができる。

デバッグ書き込みを送る smbd のシグナル・ハンドラは再入可能になっていない。 ゆえにそれらを発行する前に、 smbd が到達する SMB を待つ状態に入るまで待たなければならない。 select 呼び出しの前にシグナルのブロックを解除し、 呼び出しの後で再びブロックすればシグナル・ハンドラを安全にすることができるが、 これはパフォーマンスに影響するだろう。

バグ

知られているものはない。

作者

オリジナルの Samba ソフトウェアと関連するユーティリティは、 Andrew Tridgell (samba-bugs@samba.org) によって作成された。 また、Andrew はこのプロジェクトのソースの管理者でもある。

貢献者の完全な一覧およびバグ報告、コメント、その他を提出する方法の詳細は、 smb.conf (5) を参照のこと。

日本語訳

佐藤文優 (fumiya@cij.co.jp)
最終更新日 1998/10/02