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 クライアントに サービスすることができる。 サーバが提供できるサービスの広い説明は、それらサービスの属性を制御する 構成ファイルのマニュアルに与えられている( smb.conf(5) を参照)。 このマニュアルはサービスついて記述しないが、 サーバを動作させる上での管理の面に専念する。 このサーバを動作させることは重要なセキュリティーとの関係があること、 そして smb.conf(5) はインストールを進める前の必須の読み物であるとみなされることに注意してください。 セッションはクライアントに要求されるたびに作られる。 各クライアントは各セッションに対するサーバの複製を得る。 この複製はセッションの間、クライアントによるすべての接続を供給する。 クライアントのすべての接続が切断されると、そのクライアントに対するサーバの複製は終了する。 構成ファイルは変更されると自動的に再読み込みされる。 サーバに SIGHUP を送ることにより再読み込みを強制することができる。

オプション
-D
    このパラメータが指定されると、サーバはデーモンとして動作することになる。 つまり、自身を分離してバックグラウンドで走り、適切なポートの要求をさばく。 既定ではサーバはデーモンとして動作しない。
-a
    このパラメータが指定されると、ログ・ファイルはそれぞれの新しい接続とともに上書きされる。 既定ではログ・ファイルは追加される。
-d debuglevel
    debuglevel は 0 から 5 の整数である。 このパラメータが指定されないときの既定値はゼロである。 より高い値では、サーバの作業に関するより多くの詳細がログ・ファイルに記録される。 レベル 0 では、重大なエラーや深刻な警告のみ記録される。 レベル 1 は毎日動作させるには最適なレベルである - これは作業の実行についての少ない量の情報を生成する。 1 より上のレベルはかなりの量の記録データを生成するため、 問題を調査するときのみ使用されるべきである。 3 より上のレベルは開発者によってのみ使用されるように設計されており、 そのほどんどが非常に謎めいている膨大な量の記録データを生成する。
-l log file
    指定されると、 logfile の指定を基本としたファイル名に、動作しているサーバからの作業上の情報が記録される。 既定の基本となる名前はコンパイル時に指定される。 基本となる名前は実際の記録ファイルの名前を作り出すために使用される。 たとえば、名前として "log" が指定されると、以下のファイルがデータ記録に使用される:
        log.debug (デバッグ情報を含む) log.in (入力処理のデータを含む) log.out (出力処理のデータを含む)
    生成されたログ・ファイルがサーバによって削除されることは決してない。
-O socket options
    詳細は smb.conf(5) の socket options の節を参照。
-p port number
    port number は正の整数値である。 このパラメータが指定されていないときの既定値は 139 である。 この数字は、クライアント・ソフトウェアからサーバへの接続を確立するときに 使用されるポート番号である。 サーバの標準的な(有名な)ポート番号は 139 であり、それ故に既定である。 あなたが root ではないふつうのユーザでサーバを動作させたいならば、 多くのシステムでは 1024 より大きいポート番号を使用することを要求するだろう - あなたがこの状況にいるかどうかは、あなたのシステムの管理者に尋ねなさい。 このパラメータは上記の状況を除いては通常指定されない。
-s configuration file
    既定の configuration file の名前はコンパイル時に決定される。 指定されたファイルはサーバが必要とする構成の詳細を含んでいる。 このファイルの情報は、サーバが提供するすべてのサービスの記述はもちろん、 どの printcap ファイルを使用するかといったようなサーバの詳細な情報を含む。 さらなる情報は smb.conf(5) を参照。

ファイル
/etc/inetd.conf
    サーバを inetd メタ・デーモンによって動作させるには、 このファイルにメタ・デーモン用の適当な始動情報を含める必要がある。 下の "インストール" の節を参照。
/etc/rc
    (あるいは、あなたのシステムが使用するあらゆる初期化スクリプト) 始動時にデーモンとしてサーバを動作させるなら、 このファイルにサーバ用の適切な始動順序を含める必要がある。 下の "インストール" の節を参照。
/etc/services
    inetd メタ・デーモンを介してサーバを動作させるなら、 このファイルにサービス・ポート(例: 139)とプロトコル・タイプ(例: tcp)に対する サービス名(例: netbios-ssn)のマッピングを含める必要がある。 下の "インストール" の節を参照。
/usr/local/samba/lib/smb.conf
    このファイルはサーバがクライアントに利用されるように用意するための すべてのサービスを記述する。 さらなる情報は smb.conf(5) を参照。

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

環境変数
PRINTER
    プリント・サービスに指定されている名前がないとき、 多くのシステムでは使用するプリンタ名として、 この変数の値が(もしくは変数が定義されていないなら "lp"が)利用される。 しかしながらこれはサーバーの特性であるという訳ではない。

インストール
サーバの位置やサーバがサポートするファイルは個々のシステム管理者の問題である。 従って以下は単なる提案である。 サーバ・ソフトウェアは、すべての人に読み出し可能で root によってのみ 書き込み可能なディレクトリ /usr/local/samba 階層の下にインストールすることを推奨する。 サーバ・プログラムはそれ自身、サーバを自ら動作させたい(この場合、もちろんユーザ権限で動作する) と望むユーザすべてによって実行可能にしなくてはならない。 サーバは setuid するべきではない。 いくつかのシステム上では、smbd をからのグループに setgid する価値があるだろう。 その理由は、いくつかのシステムでは、 ユーザになるデーモン・プロセスがデバッガによってアタッチできることによる セキュリティー・ホールを持っていることにある。 smbd ファイルをからのグループに setgid することによって、 このホールが利用されるのを防ぐことができる。 このセキュリティ・ホールと提案した修正は、この文書執筆時の Linux にのみ確認されている。 いまのところ Linux を除くほかのシステム上のテストでは免疫性があることが示されており、 このホールは Linux にのみ存在する可能性がある。 サーバのログファイルは、ログファイルに鋭敏な情報を入れるために、root に よってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。 構成ファイルは、サーバによって提供されるサービスのセキュリティを制御するために、 root によってのみ読み出しと書き込みが可能なディレクトリに配置するべきである。 お望みなら構成ファイルは全員に読み出し可能にすることができるが、 サーバを正しく動作させる上で必要なことではないし、推奨されることでもない。 サンプルの構成ファイル "smb.conf.sample" がサーバのソースとともに配布されている - これを "smb.conf" にリネームし、あなたの必要を満たすように変更しても良い。 残りの注意事項は以下を仮定している:
    smbd (サーバ・プログラム) は /usr/local/samba/bin にインストールする smb.conf (構成ファイル) は /usr/local/samba/lib にインストールする ログ・ファイルは /var/adm/smblogs に保存する
サーバはユーザによって、または起動時にデーモンとして起動されるか、 もしくは inetd のようなメタ・デーモンからリクエストによって起動される。 デーモンとして起動する場合、サーバは常に用意されているため セッションの開始はより高速になる。 メタ・デーモンから起動する場合、いくらかのメモリが節約されたり、 特別なセキュリティのために TCP-wrapper tcpd のようなユーティリティを 使用することができる。 あなたの結論が出たなら、"サーバをデーモンとして起動する" または "サーバをリクエストによって起動する" のどちらかを続けて読みなさい。

サーバをデーモンとして起動する
サーバをコマンドラインからデーモンとして起動するには、単純にコマンドラインに -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 と同時にネームサーバ 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 のサービス名に一致することに注意して欲しい。 システムに合わせて次の行を適当な値にして使いなさい( 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]
         writable = yes
    [printers]
         writable = no
         printable = yes
         path = /tmp
         public = yes
これは、ホームディレクトリへの接続と、ホストでサポートされている (ユーザの権利を許可している)あらゆるプリンタへの印刷を認める。

インストールのテスト
サーバをデーモンとして起動するなら、進む前にサーバを実行しなさい。 メタ・デーモンを使用するなら、システムを再起動するか メタ・デーモンを止めて再起動しなさい。 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)

診断
[この節は工事中である] サーバによって出されたほとんどの診断は、指定されたログファイルに記録される。 ログファイルの名前はコンパイル時に指定されるが、コマンドラインで変更することもできる。 利用できる診断の数と性質は、サーバで使用されるデバッグ・レベルに依存する。 もし問題を抱えているなら、デバッグ・レベルを 3 に設定してログファイルに目を通しなさい。 ほとんどのメッセージは適度に自明である。 不幸にも、このマニュアルを作成した当時はソースコードがまだ流動的であったため、 一つ一つの診断の記述を説明できない。 この段階においてもっともよい行動は、ソース・コードを grep して、 あなたが見た診断の源となった状態を診断することである。

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

作者
オリジナルの Samba ソフトウェアと関連するユーティリティは、 Andrew Tridgell (samba-bugs@samba.anu.edu.au) によって作成された。 また、Andrew はこのプロジェクトのソースの管理者でもある。 貢献者の完全な一覧と、バグ報告、コメント、その他を提出する方法の詳細は、 smb.conf(5) を参照のこと。

日本語訳
 佐藤文優 (fumiya@cij.co.jp, fumiya@yk.rim.or.jp)