この記事で学ぶ内容は、以下のとおりです。

• Samba サーバーの構成ファイルの構造
• Samba の変数および構成パラメーターの使い方
• SMB (Server Message Block)/CIFS (Common Internet File System) で使用する主要な TCP/UDP (User Datagram Protocol) ポートについて
• Samba のロギングを構成する方法
• Samba に関する問題のトラブルシューティングとデバッグを行う方法

この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 312 の目標 312.1 の試験対策となります。この目標の重要度は 6 です。

前提条件

この連載記事を最大限に活用するには、Linux の高度な知識と、記事に記載されたコマンドを演習できる実際の Linux システムが必要です。さらに、ファイルおよびプリント・アクセスのテストに使用できる Windows 環境を利用できることも条件となります。

上に戻る

Samba の構成ファイル

Samba を構成するには、ほとんどの UNIX デーモンと同じく、バイナリー・ファイルを編集するためのグラフィカル・ツールではなく、人間が読んで理解できるテキスト・ファイルを使用します。構成ファイルのうち、最も重要なのは smb.conf です。このファイルには、使用する環境で Samba を実行するために必要なすべてのパラメーターが格納されます。

注: smb.conf はテキスト・エディターで編集するように作られていますが、Samba チームは Samba Web Administration Tool という Web ベースのツールも考案しました。また、その他にもテキスト・エディターの代わりに使用できるツールがあります (webmin など)。重要な点として、これらのツールを実行する前でも、実行した後でも smb.conf を編集できることを覚えておいてください。それは、操作している対象がテキスト・ファイルだからです。

Samba の構成ファイルのフォーマットは非常に単純です。このフォーマットでは、以下の 3 種類の構成体しか使用されません。

• セクション: セクションは、構成を独立したいくつかの領域に区分します。例えばファイル共有には、ファイル共有に固有のセクションがあります。
• パラメーター: パラメーターは、キーと値のペアです。キーは、例えば read only などの周知の属性です。
• コメント: コメントを使用することで、構成に影響することなく、構成ファイルに注釈を追加することができます。例えば、共有について記載しているヘルプ・デスク・チケットを示すなどの注釈などです。

セクション

セクションは、構成ファイルを異なる領域に区分します。セクションは角括弧 ([]) で囲まれたセクション名から始まり、次のセクションが定義されるまで、またはファイルの終わりに達するまで続きます。

以下の 3 つのセクション名には、特別な意味があります。

• global: このセクションに含まれる構成はすべて、サーバー全体に適用されます。global セクション内の構成項目は、共有レベルで変更することができます (必要な場合)。
• homes: homes セクションは、すべてのユーザーのホーム・ディレクトリーに対する共有設定用テンプレートの役割をします。Samba では、このセクションの構成にユーザー名をパラメーターとして割り当てることができるため、ユーザーにホーム・ディレクトリーを用意するたびに、いちいち個別の共有設定を構成する必要はほぼありません。
• printers: このセクションは、プリンターに使用されるという点を除き、homes と同様です。

使用されているセクション名が上記のどれでもない場合、それはファイル共有またはプリンター共有と見なされます。

特定の共有名に対する接続要求が Samba に到着すると、デーモンはその共有名が付けられたセクション (つまり、その共有のプロパティーを定義しているセクション) を探します。該当するセクションが見つからない場合、Samba はその接続がユーザーに関するものであるかどうかを確認するために、システム上のユーザーのリストを調べます。一致するユーザーが見つからなければ、今度はシステム・プリンターのリストで、その名前のプリンターが存在するかどうかを調べます。接続がユーザーと一致した場合には、homes セクションの構成が使用され、プリンターと一致した場合には、printers セクションが使用されます。いずれにしても、それぞれのセクション・レベルの構成は global セクションの構成よりも優先して適用されます。

上記のどの場合にも当てはまらない場合、最後にもう 1 つのチェックが行われます。それは、デフォルト・サービスが構成されているかどうかを調べることです。デフォルト・サービスが構成されている場合にはそのサービスが使用され、構成されていない場合にはエラーがクライアントに返されます。デフォルトでは、デフォルト・サービスは構成されないため、誤った共有名が指定されるとエラーになります。

パラメーター

パラメーターは、key = value の形で値をキーに割り当てます。キーのすべては、smb.conf の man ページにドキュメント化されています。Samba を構成する作業は、主に、目的とする動作を実現するために必要なキーを理解し、どの値を使用するのが適切であるかを判断するという作業です。

通常、パラメーターはストリングを値として取ります。Samba はマクロをサポートするため、共有名やユーザーからの入力などの項目に応じてパラメーターの値を変えることができます。例えば、デフォルトでは homes セクションはユーザーの UNIX ホーム・ディレクトリーに設定されますが、マクロを使用すれば、このパラメーターに任意の場所を指定して、接続時にユーザー名をファイル・パスに含めることができます。マクロは % 文字で始まります。これについては、マクロが必要になったときに説明します。

パラメーターの値が複数の行にまたがる場合には、最後の行を除くすべての行の終わりにバックスラッシュ (\) を付ける必要があります。これは、UNIX シェルと同様です。

コメント

コメントは、セミコロン (;) またはシャープ記号 (ハッシュ、つまり #) で始まります。コメントを使用して、項目がそのように設定されている理由を説明したり、変更内容を記録したり、セクションの境界を示したりすることができます。

構成の例

リスト 1 の smb.conf ファイルの例には、このファイルを構成する各要素が示されています。

# This is a comment
; So is this
# Remember that all shares need to be entered in the Wiki! -Opsteam
[global]
  workgroup = BIGCO
  # %v gets expanded to the version of Samba
  server string = Samba Server Version %v
  # By default any file starting with . will have the hidden attribute set
  hide dot files = yes

# Home directories come from the UNIX password file
# anyone matching a user will use this section
[homes]
  comment = Home directories
  # dot files will be hidden because it's a global

[printers]
  comment = System printers
  printable = yes

# A share that everyone can see
[projecta]
  path = /var/spool/projects/projecta
  # Override the global version of hiding dot files
  hide dot files = no

以下に、この構成例で特に注目すべき点を記載します。

• 2 種類のコメントが使用されています。一方はハッシュで始まり、もう一方はセミコロンで始まっています。
• このファイルで定義している共有は、projecta という共有だけです。これ以外のすべての共有は、システムに定義されたユーザーおよびプリンターから自動的に作成されることになります。
• server string パラメーターは、その値の一部として %v マクロを使用しています。実行時には、%v が Samba のバージョンに置き換えられます。
• hide dot files はグローバル・レベルでは yes に設定されていますが、projecta 共有の中では no に設定されています。ホーム・ディレクトリーは homes セクションの構成を使用するため、ホーム・ディレクトリーのドット・ファイル (例えば、.profile など) は非表示になります。一方、projecta 内のドット・ファイルは表示されることになります。

上に戻る

Samba によるネットワーク・サービス

Samba は IP をベースに稼働するネットワーク・サービスなので、同じく IP を使用するネットワーク上の他のホストと通信することができます。Samba 管理者は、接続に関する問題のトラブルシューティングを行うためには、Samba によるサービスがネットワーク上でどのように振る舞うかを理解しておかなければなりません。

大まかに分けると、Samba が提供するネットワーク・サービスには以下の 3 種類があります。

• ファイル共有とプリンター共有: ファイルおよびプリンターを他のネットワーク・デバイスに提供するとともに、他のマシン上のファイル・サービスおよびプリンター・サービスを使用します。
• ネーム・サービス: Microsoft ネットワークに参加するために必要な名前解決サービスです。
• ドメイン・サービス: さまざまな Microsoft サーバーの役割 (従来のドメイン・コントローラーなど) に取って代わることのできる Samba は、より新しい AD DS (Active Directory Domain Services) サーバーを統合します。

ファイル共有とプリンター共有

ファイル共有とプリンター共有は、Samba デーモンの 1 つである smbd 内に実装されます。Microsoft のファイル共有が最初に IP の世界に参入したときに使用していたのは、NetBIOS (Network Basic Input/Output System) over TCP です。この方式は TCP ポート 139 を使用して、NetBIOS の形で渡される内容を TCP セッションに組み込みます。

NetBIOS プロトコルには複数の機能が含まれますが、TCP ポート139 はセッション・サービス (つまり、ファイル転送とメッセージ・パッシング) 専用です。名前のルックアップ・サービスは、このポートでは扱われません。

NetBIOS over TCP は役立つものの、NetBIOS と TCP がそれぞれに提供するセッションおよび信頼性の機能には重複するものがあります。そこで若干の変更を加えた結果、SMB/CIFS を直接 TCP で実行できるようになりました。これは、ダイレクト・ホスティングと呼ばれる方法で、SMB/CIFS プロトコルを単純化するために使用されています。ダイレクト・ホスティングには TCP ポート 445 が使われます。

プロトコル・スイートから NetBIOS が排除されたことによって、Microsoft には名前のルックアップを処理する別の方法が必要になりました。その方法として自然な選択だったのは、DNS (Domain Name System) です。これが、DNS が AD DS のベースとなっている理由です。

Samba はデフォルトで、ポート 139 と 445 をリッスンします。この振る舞いは、グローバル・パラメーター smb ports を使って変更することができます。例えば smb ports = 445 とすると、Samba はポート 445 だけをリッスンすることになります。Samba には任意のポートをリッスンさせることができますが、標準以外のポートを使用する場合には、Samba に接続しようとしているクライアントに、そのポートを使用するように指示しなければなりません。

Samba がどのポートをリッスンしているかがわからない場合には、netstat コマンドを使って調べることができます。リスト 2 に、このコマンドの使用方法を示します。

# netstat -antp | grep smbd
# netstat -antp | grep smb
tcp   0  0 :::445                    :::*                       LISTEN      2830/smbd
tcp   0  0 ::ffff:192.168.1.143:445  ::ffff:192.168.1.147:4724  ESTABLISHED 2877/smbd

リスト 2 では、netstat コマンドを実行し、grep によって、コマンドの出力から smb というストリングが含まれる行のみが抽出されるようにフィルタリングしています。ここで指定している netstat オプションでは、すべて (-a) の TCP (-t) 接続を数値 (-n) 形式で、関連するプロセスの名前 (-p) とともに表示します。出力結果として示されている 2 行のうち、最初の行には LISTEN というストリングが示されています。これは、デーモンが着信接続をリッスンしていることを意味します。この場合、デーモンがリッスンしているのはポート 445 です。2 番目の行に示されている ESTABLISHED は接続状態であることを示しており、ここでは 192.168.1.147 がローカル・ホスト (192.168.1.143) のポート 445 で接続されています。したがって、リスト 2 の出力からは、smbd がポート 445 のみをリッスンしていること、そして 1 つのクライアントが接続されていることがわかります。

ネーム・サービス

NetBIOS が提供するネーム・サービス層の役割は、ネットワークをブラウズして名前をルックアップすることです。例えば、UDP ポート 137 で NetBIOS ネーム・サービス・リクエストを使用することによって、ホスト SERVER1 が IP アドレスに解決されます。ブラウズのサポートとサポートの役割 (マスター・ブラウザーなど) の選択は、データグラム・サービス・ポートとも呼ばれる UDP 138 で行われます。ネーム・サービスは nmbd デーモン内に実装されます。

重要な点として、ネーム・サービスは TCP ではなく、UDP を使用することに注意してください。UDP パケットは単一のユニキャスト・ストリームではなく、コネクションレスであり、すべてのホストにブロードキャストされます。UDP のブロードキャスト機能により、ネットワークでの NetBIOS ネーム・サービスの処理が容易になります。

Samba バージョン 3 には nmbd がリッスンするポートを制御するパラメーターはありませんが、Samba バージョン 4 ではグローバル・パラメーターとして、nbt port および dgram port を実装しています。この 2 つは、それぞれネーム・サービスのポート、データグラム・サービスのポートを制御するパラメーターです。

リスト 2 に示したようなコマンドを使用すると、nmbd によってどのポートが開かれているかが示されます。リスト 3 は、その一例です。

# netstat -anup | grep nmbd
udp        0      0 192.168.1.255:137       0.0.0.0:*        2975/nmbd
udp        0      0 192.168.1.143:137       0.0.0.0:*        2975/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*        2975/nmbd
udp        0      0 192.168.1.255:138       0.0.0.0:*        2975/nmbd
udp        0      0 192.168.1.143:138       0.0.0.0:*        2975/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*        2975/nmbd

リスト 3 では、smbd の代わりに nmbd を調べているというだけでなく、netstat の -u オプションを使って TCP ポートの代わりに UDP ポートを調べています。その結果、nmbd はさまざまなインターフェースでポート 137 と 138 をリッスンしていること、そしてブロードキャスト・アドレス 192.168.1.255 をリッスンしていることを示す一連の行が出力されます。どちらのネーム・サービスのポートも、ホスト間通信およびブロードキャスト通信を利用しています。

ドメイン・サービス

Samba チームは絶えずソフトウェアの更新を続けています。その目的は、ソフトウェアを Microsoft ネットワークとより緊密に統合すること、そして Microsoft インフラストラクチャーを置き換えることです。そのためには、Samba が Microsoft インフラストラクチャーのサービスをネットワーク上でエミュレートする必要があります。

エミュレートするサービスのほとんどには、何らかの形で Kerberos と LDAP (Lightweight Directory Access Protocol) が関わってきます。これは高度なトピックなので、今後の記事で詳しく取り上げることにします。とりあえずは、Samba にはファイル共有以上の機能があることを覚えておいてください。

Samba が使用するポートの要約

表 1 に、Samba デーモンがファイル共有に関してリッスンするポートを要約します。

「サービス」列に記載したタグは、/etc/services というファイルに記述されている既知のサービス名です。この services ファイルは、アプリケーションがサービス名をポート番号に解決するのに役立つだけでなく、人間がポート番号をサービス名と関連付ける際にも役立ちます。ほとんどのサービスは TCP ポートと UDP ポートを予約しますが、アプリケーションは必ずしも UDP と TCP の両方を使用しなければならないというわけではありません。この両方を予約する理由は、2 つの異なるサービスが同じポート番号を異なるプロトコルで使用しようとする際の混乱をなくすためです。

もう 1 つ指摘しておく価値がある点として、/etc/services に記述されている番号および名前は強制ではありません。このファイルに記述されているのとは異なるポートでデーモンを実行することもできます。ただし、それにはポートの変更をクライアントに伝達できることが条件となります。クライアントが標準ポートを使用することを要求しない限り、Samba を例えばポート 5137 から 5139 およびポート 5445 で実行することもできます。

上に戻る

Samba に関する問題のトラブルシューティング

Samba では問題がまったく発生しないわけではありません。Samba に関する問題は、システム管理者によって引き起こされることも、ユーザーが原因で生じることもあります。その場合、どこに問題があるのかを突き止めて、それを解決する方法を見つけることが、システム管理者の役目です。

構成ファイルをテストする

Samba が起動しない場合、あるいは構成ファイルに誤りがないことを確認したい場合には、testparm ユーティリティーが役に立ちます。このユーティリティーは smb.conf が正しく記述されているかどうかをチェックします。リスト 4 に、エラーがある場合の testparm の実行結果を示します。

# testparm
Load smb config files from /etc/samba/smb.conf
Unknown parameter encountered: "hide dto files"
Ignoring unknown parameter "hide dto files"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[public]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        workgroup = MYGROUP
        server string = Samba Server Version %v
        passdb backend = tdbsam
        log file = /var/log/samba/log.%m
        max log size = 50
        cups options = raw

<< rest of the output omitted >>

testparm の出力は、ファイルの場所から始まります。別のファイルを指定したい場合には、以下のように、そのファイルの名前をコマンドラインで渡します。

testparm /home/me/smb.conf

ファイルの場所に続いて、testparm は、hide dto files というパラメーターが無効であると指摘しています。このパラメーターは本来、hide dot files となっているべきものです。

構成ファイルの処理が行われた後、サーバーの役割と構成ファイルの簡略版が示されます。この簡略版はコメントが取り除かれて一貫性のあるフォーマットで示されるため、テキスト・エディターで smb.conf を見ていたときには見逃していたエラーが見つかることもあります。

変更した後の構成ファイルで testparm を実行してください。Samba は、構成ファイル内の誤字はほとんど無視します。また、起動時に常にメッセージをコンソールに出力するわけではありません。そのため、この種の誤りは、実際に何かが適切な動作をしなくなるまで見逃してしまうことがよくありますが、testparm は、smb.conf に含まれる誤字に対してアラートを出します。

デフォルトで testparm が表示するのは、smb.conf に入力された構成だけです。デフォルト値をどこかで使用している疑いがある場合には、-v オプションを使用すると、testparm にデフォルト値も表示させることができます。

testparm のもう 1 つの使い方として、出力を単一のセクションまたはパラメーターに絞り込むこともできます。リスト 5 に、testparm を使用して security mask オプションの値を確認する例を記載します。

# testparm -s --parameter-name "security mask"
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[public]"
Loaded services file OK.
0777

リスト 5 で使用している -s パラメーターは、testparm が smb.conf を構文解析した後、ユーザーからの入力を待たずに結果を画面に表示するためのものです。次に --parameter name "security mask" を指定して、security mask の値を要求します。結果は 0777 で、これはデフォルト値です。このモードでは、-v を指定しなくてもデフォルト値が示されます。

クライアントとして接続する

ユーザーのデスクトップまで出向いて行って直接いろいろと試してみる代わりに、自分のデスクに居ながらにしてコマンドラインからかなりの種類のテストを行うことができます。なかでもまず始めに行うべき基本的なテストは、Samba ポートに接続できるかどうかを確認することです。それには、telnet コマンドを使用するのが最も簡単な方法となります (リスト 6 を参照)。

# telnet bob 139
Trying 192.168.1.134...
telnet: connect to address 192.168.1.134: Connection refused

リスト 6 では、root ユーザーがサーバー bob にポート 139 で接続しようとしていますが、ポート 445 を使用してダイレクト・ホスティング SMB ポートをテストすることもできます。上記のテスト結果は、Connection refused です。これは、デーモンが該当するポートでリッスンしていないか、ファイアウォールによって接続がブロックされていることを意味します。これと同じことを表す結果としては、No route to host または Connection timed out などがあります。

一般に、クライアントがサーバーに接続するために使用するのはサーバーの名前であって、サーバーの IP アドレスではありません。telnet を使用して IP アドレスではなく名前でサーバーに接続する場合には、返される IP アドレスに特に注意が必要です。上記の例では、サーバー (bob) は 192.168.1.134 に解決されましたが、DNS レコードにエラーが含まれている可能性がまったくないわけではありません。DNS レコードが誤っている場合、クライアントは誤ったアドレスに接続されることになります。

Windows 名前解決に DNS を使用していない場合には、nmblookup コマンドを使って NetBIOS 名のルックアップを実行することができます。リスト 7 は、サーバー bob に対して問い合わせをする例です。

# nmblookup bob
querying bob on 192.168.1.255
192.168.1.138 bob<00>

リスト 7 の結果によると、サーバー bob には、リスト 6 に示されていた 192.168.1.134 ではなく、192.168.1.138 が割り当てられています。この結果は、特にポート 139 および 445 が 192.168.1.138 で応答している場合の DNS の問題を指摘しています。

もう 1 つのテストは、構成ファイルのなかで特定ホストへのアクセスが禁止されているかどうかを調べることです。この場合にも、testparm を使用します (リスト 8 を参照)。

# testparm /etc/samba/smb.conf  seanspc 192.168.1.147
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[public]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Deny connection from seanspc (192.168.1.147) to homes
Deny connection from seanspc (192.168.1.147) to printers
Deny connection from seanspc (192.168.1.147) to public

リスト 8 の testparm には、以下の 3 つの項目が渡されます。

• Samba 構成ファイルのパス
• テストするマシンの NetBIOS 名
• テストするマシンの IP アドレス

リスト 8 の出力には、テスト対象のマシンが、すべての共有に対してアクセスを拒否されていることが示されています。このモードで使用する testparm ユーティリティーは、実際にテスト対象のマシンとして接続するわけではありません。代わりに testparm は構成ファイルを処理して、アクセスが許可されているかどうかを調べます。

これまでのテストがすべて成功した場合には、smbclient ユーティリティーを使用してクライアントに接続してみてください。最初のテストでは、共有リストを表示できるかどうかを試します (リスト 9 を参照)。

[sean@bob source3]$ smbclient -L '\\bob'
Enter sean's password:
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13]

        Sharename       Type      Comment
        ---------       ----      -------
        extdrive        Disk
        Sean Walberg's iMac Disk
        timemachine     Disk
        IPC$            IPC       IPC Service (Samba Server Version 3.5.6-69.fc13)
        test            Printer   test
        Downstairs_Laser Printer   HP 6L
        Cups-PDF        Printer   Cups-PDF
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13]

        Server               Comment
        ---------            -------
        BOB                  Samba Server Version 3.5.6-69.fc13

        Workgroup            Master
        ---------            -------
        MYGROUP              BOB
        WORK                 SWALBERG-XPLT
        WORKGROUP            IMAC-1FC525

リスト 9 では、ユーザーが -L パラメーターを指定して、サーバー bob 上の共有名の一覧を要求しています。サーバー名が連続した 2 つのバックスラッシュ (\\) で始まっている理由は、これが UNC (Universal Naming Convention) パスであるためです。単一引用符を使用するか、二重引用符を使用するかについても、注意して選択する必要があります。単一引用符で囲むことで、バックスラッシュはエスケープされた文字として扱われます。

これよりも厳しいセキュリティーがサーバーにセットアップされている場合には、-U パラメーターと -W パラメーターで、それぞれユーザー名、ドメイン名を渡す必要があります。

最後に、-L パラメーターを省略し、共有の完全 UNC パスを使用して共有への接続を試してみることができます。リスト 10 に示すクライアントは、別のワークグループとユーザー名を使用してサーバーに接続しようとしています。

[sean@bob source3]$ smbclient '\\swalberg-xplt\photos' -U swalberg -W WORK
Enter swalberg's password:
Domain=[WORK] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: \> dir
  .                                   D        0  Thu Jan  6 11:39:50 2011
  ..                                  D        0  Thu Jan  6 11:39:50 2011
<< files omitted >>
                38156 blocks of size 4194304. 2938 blocks available
smb: \>>

以上のテストに合格すれば、問題は Samba の構成にあるのではなく、クライアントとサーバーの間、あるいはクライアント自体のどこかに存在することがかなり確実になります。どこに問題があるかについては、次のセクションで説明するログが手掛かりになります。

上に戻る

ロギングとデバッグ

ロギングとトラブルシューティングを切り離して考えることはできません。問題が発生した場合、ログで過去を振り返ることによって、エラーの有無を確認し、エラーが発生している場合にはその詳細を調べることができます。何かが正常に動作していない理由を調査する際には、必要な詳細レベルの情報を取得できるまで、ログに記録する情報量を増やすことができます。Samba では、ロギングを操作するための多数のパラメーターを smb.conf に用意しているので、これらのパラメーターを組み合わせて使用することで、生成されるログのタイプを調整することができます。

Samba は、syslog 機能にログを記録できるとともに、独自のログ・ファイルを生成できるという点で、従来の UNIX デーモンのように振る舞います。さらに、Microsoft Event Viewer ツールで Samba サーバーに接続してログを取得することもできますが、その場合の機能の欠点は、Samba が直接イベント・ログ・フォーマットでログを記録できないことです。したがって、Samba ツールを使ってログ・ファイルを事後処理しなければなりません。

ログ・レベル

Samba が生成するログ・メッセージには、それぞれにレベルがあります。レベルは 0 から 10 までの整数で、より重要なメッセージほど (新規接続、重大なエラーなど)、ログ・レベルは低い値となります。デバッグ・メッセージの場合のログ・レベルは高い数値です。ロギングの情報量を制御するには、ログに記録する最大レベルを指定します。ログ・レベル 1 で記録されるのは、優先度 0 または 1 のメッセージだけです。広範なメッセージをログに記録するには、これよりも高い数値を指定します。

3 より高いログ・レベルは、開発者用に意図されているため、システム管理者にはそれほど役に立ちません。ログ・レベルを 0 に設定すると、少数の起動メッセージと重大なエラーしか記録されなくなります。

ログ・レベルを構成するには、global セクションの log level パラメーターを使用します。例えば、log level = 2 とすると、ログ・レベルは 2 に設定されます。この設定では、優先度 2 以下のすべてのメッセージがログに記録されます。

ログ・レベルは、実行時に変更することができます。ログ・レベルを高くするには SIGUSR1 シグナルを Samba プロセスに送信し、ログ・レベルを低くするには SIGUSR2 を送信します。

ログ・レベルの粒度をさらに細かくし、ロギング対象のクラスを指定することによって、特定の機能での詳細だけを記録することもできます。ロギング対象のクラスは、以下に示すとおりです。

• all: このパラメーターはオプションです。追加のキーワードを指定しなければ、all が前提とされます。
• tdb: 通常のデータベース、つまり Samba が使用するキー・バリュー型ストアに関連するログ・メッセージ。
• printdrivers: プリンター・ドライバー管理ルーチン。
• lanmanlanman: NT LAN Manager のデバッグ。
• smbsmb: SMB プロトコルのデバッグ。
• rpc_parse: リモート・プロシージャー・コール (RPC) の構文解析。
• rpc_srv: サーバー・サイドの RPC。
• rpc_cli: クライアント・サイドの RPC。
• passdb: Samba ホストでパスワードを保管するための古い方法。
• sam: ローカル Samba アカウント・データベース。
• auth: ユーザー認証に関連する Samba 内部の各種モジュール。
• winbind: Microsoft ユーザーがトランスペアレントに UNIX システムにログインできるようにするためのコンポーネント。
• winbind:プラガブル・モジュールによって Samba に機能を追加するために使用する VFS (Virtual File System: 仮想ファイルシステム) モジュール用のデバッグ・メッセージ。
• idmap: UNIX ユーザー ID と Microsoft セキュリティー ID の間のマッピング。
• quota: Microsoft Windows NT ポリシーおよび UNIX ファイルシステムによるクォータ処理に関連するメッセージ。
• acls: アクセス制御リストの処理。
• locking: ファイルのロック状況およびエラー。
• msdfs: Samba の分散ファイルシステム・サポートに関連するログ・メッセージ。
• dmapi: データ管理アプリケーション・プログラミング・インターフェース (API) 機能。この機能を使用するには、Samba をサード・パーティーの DMAPI 実装でコンパイルする必要があります。
• registry: Windows レジストリーのエミュレーション。

上記のさらに詳細なロギングを使用するには、log level パラメーターの後に、キーワードと値をコロン (:) で区切って追加します。例えば、log level = 1 winbind:3 とすると、システムのデフォルト・ログ・レベルが 1 に設定され、winbind ログ・レベルが 3 に上がります。この変更によって、関連性のないログ・ファイルの山に埋もれることなく、シングル・サインオンでの問題をデバッグすることができます。

ログ・ファイルの保管場所

ログ・ファイルの名前を変更するには、log file パラメーターを使用します。値には、マクロを含めることもできます。よく使用される設定の 1 つは、クライアントごとにログ・ファイルを分けることです。それには、以下のように指定します。

log file = /var/log/samba/log.%m

このコマンドは、個々のログ・ファイルをクライアントごとに 1 つのファイルに分けて、残りのメッセージは引き続き log.smbd に記録されるようにします。

syslog にログを記録する場合、syslog = 1 と指定すれば、レベル 1 または 0 のすべてのログがローカル syslog サーバーに送信されます。この場合、Samba は LOG_DAEMON 機能を使用し、Samba のログ・レベルを以下のように syslog の優先度に対応付けます。

• LOG_ERR: ログ・レベル 0 です。
• LOG_WARNING: ログ・レベル 1 です。
• LOG_NOTICE: ログ・レベル 2 です。
• LOG_INFO: ログ・レベル 3 です。
• LOG_DEBUG: ログ・レベル 4 以上です。

着信メッセージをフィルタリングしてシステム管理者にアラートできる高度な syslog デーモンに対して syslog を使用している場合、この設定は Samba サーバーを監視するのに最適な方法となります。

ログのメタデータ

以下のグローバル・パラメーターを使用することで、ログ・エントリーのすべてに共通して示される情報の追加や削除をすることができます。

• debug timestamp: タイムスタンプをログ・メッセージに追加します。タイムスタンプは、デフォルトで有効に設定されます。
• debug uid: ログを生成した Samba プロセスのユーザー ID とグループ ID を記録します。
• debug prefix timestamp: タイムスタンプは有効にしますが、ログを生成した Samba ソース・コード内の場所についての情報は削除します。
• debug pid: ログを生成した Samba プロセスのプロセス ID を記録します。
• debug hires timestamp: タイムスタンプの単位を秒からマイクロ秒に変更します。
• debug class: ログ・メッセージのクラスを記録します。特定のクラスの詳細レベルを変更したい場合に重宝するパラメーターです (このオプションは、必要なクラスを判断するのに役立つため)。

ロギングは、問題を見つけるのに役立つこともあれば、過剰な情報のなかに問題を埋もれさせてしまうこともあります。Samba は多種多様なロギング・オプションを提供しているので、これらのオプションを慎重に使用してください。

上に戻る

システム・コールの追跡

以上のどの方法でも問題を見つけられない場合は、UNIX システム・ツールによって、プロセス内部で何が行われているのかを調べるという奥の手があります。Linux の strace プログラムを使用すれば、アプリケーションが行うすべてのシステム・コールを追跡することができます。アプリケーションはシステム・コールを使用して、ファイルのオープンと読み取り、プロセスの作成と破棄、そしてオペレーティング・システムの残りの部分とのやりとりを行います。

リスト 11 に、root ユーザーがクライアントにエラーをスローしている Samba プロセスを追跡する例を示します。

# ps -ef | grep smb
sean     13375 28812  0 21:54 ?        00:00:00 smbd -D
root     14294 13593  0 21:55 pts/2    00:00:00 grep smb
root     16132 28812  0 Feb27 ?        00:00:36 smbd -D
root     28812     1  0 Feb14 ?        00:00:28 smbd -D
root     28814 28812  0 Feb14 ?        00:00:00 smbd -D
[root@bob /]# strace -e trace=file -p 13375
Process 13375 attached - interrupt to quit
<< Output omitted >>
chdir("/home/sean")                     = 0
stat64("somedir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("somedir/*", 0xbfcb5f60)         = -1 EACCES (Permission denied)
getcwd("/home/sean", 4096)              = 11
lstat64("/home/sean/somedir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat64("/home/sean/somedir/*", 0xbfcb5ffc) = -1 EACCES (Permission denied)

最初のコマンドが、Samba プロセスのリストを検索します。Samba は接続したユーザーの ID を前提とすることから、プロセス 13375 がこのユーザーに属するものであることは容易に特定することができます。次の strace コマンドは、2 つのパラメーターを指定して実行されます。最初の -e trace=file は、出力をファイル関連のシステム・コールに制限します。Samba で発生するような問題には、これが最初に行う推測として有力です。2 番目のパラメーター、-p 13375 は、strace に該当するプロセス ID を持つ実行中のプロセスに接続するように指示します。

このコマンドの出力を調べると、smb は常にディレクトリーをスキャンして、変更の有無を確かめていることがわかります。ユーザーが問題のあるアクションを実行しようとすると、リスト 11 に示すような内容が出力されるはずです。最後のいくつかのコマンドは、stat64 呼び出しによって、ディレクトリー内のファイルに関する情報を取得しようとしていますが、その結果は permission denied となっています。これは、Samba によってではなく、ファイルシステム・レベルでユーザーが拒否されていることを意味します。このコマンドによって、例えばディレクトリーの属性を変更する必要があるという情報や、ディレクトリーへのアクセスがユーザーに許可されていないという情報など、問題を解決するための追加情報を入手することができます。

上に戻る

次回の予告

Samba の構成について取り上げるのは、今回の記事が最後です。次回は LPI-302 試験の目標 312.2 に備えるために、ファイル共有を作成および構成し、これらの共有に他のシステムからアクセスする方法を学びます。

参考文献

学ぶために

• ユーザー・アクティビティーをログに記録するには、Samba の仮想ファイルシステム層を使用できます。
  
  
• developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  
  
• さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  
  
• 無料の developerWorks Live! briefing に参加して、IBM の製品およびツール、そして IT 業界の傾向を素早く学んでください。
  
  
• developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  
  
• Twitter でdeveloperWorks をフォローしてください。
  
  

製品や技術を入手するために

• Samba Git リポジトリーで、Samba の最新ニュースを入手してください。
  
  
• Samba の最新バージョンを入手して、最新機能を追加してください。
  
  
• ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。
  
  

議論するために

• My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
  
  

著者について

Sean Walberg はネットワーク・エンジニアであり、ネットワークについて 2 冊の本も書いています。これまで医療やメディアをはじめ、さまざまな業界に携わってきました。

この記事を評価する

コメント

上に戻る

目次

• 前提条件
• Samba の構成ファイル
• Samba によるネットワーク・サービス
• Samba に関する問題のトラブルシューティング
• ロギングとデバッグ
• システム・コールの追跡
• 次回の予告
• 参考文献
• 著者について
• コメント