Table of Contents
この章にはサブネット越しあるいはワークグループ(ドメイン)越しのブラウジングを実行するための早わかりと、さらに詳細な情報を含んでいる。WINSはNetBIOS名からIPアドレスへの名前解決のために最適のツールである。しかし、WINSは名前->アドレス解決方法を除いてブラウズリストの扱いを改善するわけではない。
Microsoft Windows 2000とそれ以降のバージョンでは、NetBIOS over TCP/IPなしで操作するように設定できる。Samba-3とそれ以降のバージョンもこの操作モードをサポートしている。NetBIOS over TCP/IPが無効になっている場合、Microsoft Windowsマシン名の解決を行う主要な手段はDNSとActive Directory経由である。以下の情報は使用するサイトでNetBIOS over TCP/IPが動いていることを仮定している。
Charles Dickensはかつて次のような名言を言った:“それはすべての時世の中で最もよい時世でもあれば、すべての時世の中で最も悪い時世でもあった。”(訳注:二都物語の冒頭部分:佐々木 直次郎訳、青空文庫より)振り返れば振り返るほど、あったことをより切望するが、それが決して戻らないことを望む。(訳注:かなり怪しい)
多くのMicrosoft Windowsネットワーク管理者に対し、その一節はNetBIOSネットワーキングについて感じていることを要約している。NetBIOSネットワーキングをマスタした人にとって、その気まぐれな性質はよくあることである。そのやんちゃな性質を押さえ込むことが全く管理できない人にとって、NetBIOSはパターソンののろいのようである。
オーストラリアの植物問題をよく知らない人のために、パターソンののろい、すなわちエキウム・プランタギネウムは19世紀の中頃、ヨーロッパからオーストラリアに導入された。それ以来、急激に広まった。種がたくさん出来、平方メートルあたり何千の密度で、種の寿命は7年以上もあり、年中発芽する能力があり、正常な条件がそろえば、持続的に雑草として生える能力がある。
この章では、動いているNetBIOS(Network Basic Input/Output System) over TCP/IPを通して実装されているSMBに注目するServer Message Block (SMB)ネットワーキングの不可欠な側面を探求する。Sambaは他のプロトコル上でSMBまたはNetBIOSを実装していないので、ネットワーク環境で、どのように設定をするかを知る必要があり、また、すべてのMicrosoft ネットワーククライアント上でTCP/IP以外のものを使うことはないことを単に覚えておけばよい。
SambaはWINS(Windows Internetworking Name Server)を実現することと、MicrosoftのWINS拡張を実現する能力を提供する。これらの拡張は、通常の範囲のMicrosoft WINSを超えて安定したWINS動作を提供することを支援する。
WINSはNetBIOS overTCP/IPが動作しているシステムにのみ適用されるサービスである。Microsoft Windows 200x/XPはNetBIOSが無効でも動作することが出来る。そのような場合、WINSは無関係となる。Sambaはこれもサポートする。
NetBIOSが無効になったこれらのネットワークでは(すなわち、WINSを必要としない)、ホスト名の解決のためにDNSを使うことが必要である。
一般的には、ブラウジングとは、Microsoft WindowsとSambaサーバがマイネットワーク中に見える事を意味し、特定のサーバのコンピュータアイコンをクリックすると、そのサーバ上の共有と有効なプリンタを表示するウィンドウが開いて表示される。
とても単純に見えるが、これは実際には、異なった技術の複雑な相互作用によるものである。これらのすべてを行うために使われる技術(か方式)は以下を含む:
ネットワークへのMicrosoft Windowsマシンの存在を登録。
ネットワーク上の他のマシンにそれ自身を通知。
ネットワーク上の複数の1つ以上のマシンはローカルアナウンスメントをまとめる。
クライアントマシンはマシンのリストをまとめたマシンを見つける。
クライアントマシンはマシン名をIPアドレスに変換する。
クライアントマシンはターゲットマシンに接続する。
ブラウズリスト管理と名前解決を制御するSambaアプリはnmbd
である。nmbdの動作に関連する設定パラメータは以下の通り:
ブラウジング動作:
名前解決方法:
WINS動作:
(*)というマークが付いたものは通常変更が必要なオプションである。これらのパラメータが設定されていなくても、nmbd
は動作することが出来る。
Sambaでは、wins server と wins support は相互に排他的なオプションである。nmbd
が起動するとき、smb.conf
ファイル中に両方のオプションが設定されていると、起動に失敗する。nmbd
は、それ自身のWINSサーバを使わなければならないWINSサーバとして動作するために、それ自身のインスタンスをフォークする。
すべてのMicrosoft Windows ネットワークは SMBベースのメッセージングを使う。SMBメッセージングはNetBIOSがあってもなくてもよい。Microsoft Windows 200xは下位互換のために、NetBIOS over TCP/IPをサポートする。Microsoftは段階的にNetBIOSサポートを打ち切っているように見える。
Sambaは、TCP/IP上でカプセル化することによって、Microsoft Windows NT/200x/XPがするようなNetBIOSを実装している。NetBIOSベースのネットワークはブラウズリストの管理を行うために、ブロードキャストメッセージングを使う。NetBIOS over TCP/IPが動いている時、これはUDPベースのメッセージングを使う。UDPメッセージはブロードキャストかユニキャストのどちらも使える。
通常、ユニキャストUDPメッセージングのみがルータによって転送される。smb.confのremote announceパラメータはユニキャストUDBを通じて、リモートネットワークセグメントにブラウズアナウンスメントを公開することを支援する。同様に、smb.conf
のremote browse syncパラメータはユニキャストUDPを使ってブラウズリストの収集を実現する。
名前検索要求(名前解決)を実行するためにMicrosoft Windowsによって使われる方法はNetBIOSノードタイプと呼ばれる設定パラメータによって決まる。基本的なNetBIOSノードタイプは4つある:
b-node (type 0x01):UDPブロードキャストを 使ってNetBIOSブロードキャスト要求のみを使うWindowsクライアント。
p-node (type 0x02):WINSサーバに直接UDP ユニキャストを行う、ポイントツーポイント(NetBIOSユニキャスト)要求を使う Windowsクライアント。
m-node (type 0x04):、最初にUDPブロード キャストを使ってNetBIOSブロードキャストを行い、次に(NetBIOSユニキャストで) WINSサーバに直接UDPユニキャストを行うWindowsクライアント。
h-node (type 0x08):UDPユニキャスト (NetBIOSユニキャスト)を使ってWINSサーバに直接要求し、次にUDPブロードキャストを 使ってNetBIOSブロードキャスト要求をするWindowsクライアント。
既定値のWindowsネットワーククライアント(あるいはサーバ)のネットワーク設定は、NetBIOS over TCP/IPを有効にしていて、b-ノードになっている。WINSを使うと、WINSが故障か有効になっていない場合、クライアントがブロードキャストベースの名前解決を使えるように、h-ノード(ハイブリッドノード)動作が意味をなすようになる。
SambaがSMBサーバ技術のみのネットワーク中ではnmbd
のうち少なくとも1台はWINSサーバとして設定する必要がある。これは、ブラウジング環境の管理を簡単にする。もしもおのおののネットワークセグメントが固有のSamba WINSサーバを設定している場合、セグメント間のブラウジングを動作させる唯一の方法はremote announceとremote browse syncパラメータをsmb.conf
ファイルで使うことである。
もしも全体の複数ネットワークで1つだけのWINSサーバを使う場合、remote announceとremote browse syncパラメータの使用は必須ではない。
Samba-3では、WINS複製は作業中である。大量のコードがコミットされていたが、まだ改良が必要である。Samba-3.0.20のリリース時点ではまだサポートされた機能ではない。希望としては、Samba-3のどこかのリリース時点でサポートされた機能になることを予定している。開発者がこれを完了させようと思うほどの、十分な重要性がないという理由で、これは遅れている。
現時点で、SambaのWINSはMS-WINS複製をサポートしていない。これは、SambaをWINSサーバとして設定しても、ネットワーク上で、1つだけnmbd
をWINSサーバとして設定する必要がある。あるサイトでは(サブネット単位に1つのサーバを)冗長性のために、複数のSamba WINSサーバを使っていて、セグメントをまたいですべてのセグメントのブラウズリストを集めるために、remote browse syncとremote announceを使っている。この設定では、クライアントがローカル名の解決のみが出来るので、他のサブネット上を見ることができる、サーバのIPアドレスを解決するために他のサブネット上の名前を解決するためのDNSを使うように設定しなければならない。この設定は推奨されないが、実用的なやり方として(すなわち、“もしも他の場合がすべて失敗の場合”というシナリオ)、記述されている。NetBIOS over TCP/IPはとてもひどくて管理しにくいプロトコルである。この置き換えとして、NetBIOSless SMB over TCP/IP is notwithout its own manageability concerns.NetBIOSベースのネットワークは妥協とトレードオフの固まりである。WINSはDNSに格納出来ない情報を格納する。従って、DNSはNetBIOS over TCP/IPが使われている時にWINSから得られるものよりも貧弱な代わりにしかならない。WindowsクライアントはWINSを使うように設計されている。
最後に、ブラウズリストは15分間よりも短い間隔で繰り返される信頼性のないブロードキャストメッセージの集合から校正されていることに注意。これは、ブラウズリストを作成するために時間がかかると言うことであり、特に、ネットワークセグメントをまたぐ場合は、安定するまでには45分かかる可能性があるということである。
Microsoft Windows 200x/XPシステムでホスト名をIPアドレスに解決しようとする場合、以下の手順で行う:
hosts
ファイルを調べる。これは%SystemRoot%\System32\Drivers\etc
にある。
DNS 検索を実行する。
NetBIOSネームキャッシュを調べる。
WINSサーバに問い合わせる。
UDPでブロードキャストの名前検索を行う。
%SystemRoot%\System32\Drivers\etc
にあるLMHOSTSファイルのエントリを調べる。
どのようにNetBIOS over TCP/IPプロトコルが実装されているを考えた上で、WINSのみが、TEMPTATION<1C> というネットワークログオンサーバを探すためのNetBIOS名前問い合わせのようなサービス指向の名前の、信頼性のある名前検索を解決する能力を持つ。実際、Microsoft ADSでの実装は特に拡張されたサービス指向のDNSエントリ全体を管理するようになっている。このタイプの機能はNetBIOS over TCP/IPプロトコルの名前空間では実装も、サポートもされていない。
すべてのTCP/IPが有効なシステムは、いろいろなホスト名解決方法を使う。TCP/IPのホスト名解決で最初に使う方法は固定のファイル(/etc/hosts
)かDNSである。DNSはインターネットを使えるようにする技術である。DNSベースのホスト名解決はほとんどすべてのTCP/IPが有効なシステムでサポートされている。ごくわずかの組み込みシステムのみがDNSのサポートをしていない。
Windows 200x/XPはダイナミックDNSサーバ(DDNS)にそのホスト名を登録できる。Windows 200x/XP上で ipconfig /registerdns
を使うことで、ダイナミックDNSサーバに強制的に登録できる。
Active Directoyでは、正確に動作しているDNSサーバが確実に必要である。正しく設定されていて動作しているDNSサーバがない場合、Microsoft Windows クライアントとサーバはお互いを認識できず、そのためネットワークサービスはひどく使い物にならないだろう。
raw SMB over TCP/IP(NetBIOSレイヤなし)の使用は、Active Directoryドメインのみで行える。SambaはActive Directory ドメインコントローラではない:故に、NetBIOSを使わないで同じ時にSambaをドメインコントローラとして動かすのは不可能である。SambaをActive Directoryのメンバサーバ(DMS)として動かしているとき、NetBIOS over TCP/IPを使わないでSambaを設定することは可能である。Samba DMSはActive Directoyドメインに完全に統合できるが、もしも、NetBIOS over TCP/IPが無効の場合、SambaまたはADS環境のどちらかで自動的に生成されないという理由で、SambaDMS用に適切なDNSエントリを手動で作成する必要がある。
時折、Microsoft DNSサーバの代わりにUNIXベースのDDNSサーバを使いたいというUNIXネットワーク管理者の要望を聞くことがある。これが誰かにとって都合がよい間、MicrosoftWindows 200x DNSサーバはActive Directoryと共に動作するように自動的に設定される。BIND 8または9を使うのは可能だが、Microsoft Active Directoryクライアントが基本的なネットワークサービスを確実に使えるために、ホスト名を解決できるために、サービスレコード(SRVレコード)を確実に作成することがほとんど必要となる。以下は、Active Directoryが要求する既定値のサービスレコードのいくつかである:
Active Directoryで必要とされるSRV(サービス)レコードを十分にサポートする能力をBIND9を使うときに望まれるため、Active DirectoryでDDNSを使うことは強く推奨される。もちろん、ADSが動いているとき、ADSとMicrosoft DNSの間で自然な類似性があるという理由で、Microsoft固有のDDNSサーバを使うことは意味があることである。
これは、ドメイン内のWindows NT PDCアドレスを提供する。
ドメイン内のグローバルカタログのアドレスを解決する。
サイト上のドメインコントローラの一覧を提供する。
Enumerates list of domain controllers that have the writable copies of the Active Directory data store.
グローバルな一意の識別子を使うマシンをクライアントが認識するためにMicrosoft Windowsによって使われるエントリ。
サイト設定に依存するグローバルカタログサーバをクライアントが認識するためにMicrosoft Windowsによって使われる。
サンプルのドメインquenya.org
のために基本的なサービスを Microsoftクライアントが認識するために使われる特定のエントリは以下を含む:
_kerberos._udp.quenya.org UDP経由でKDCサーバに接続す るために使われる。のエントリはおのおののKDC向けにポート88にしな ければならない。
_kpasswd._udp.quenya.org ユーザのパスワード変更処理を 行わなければならない時にkpasswd
サーバを見つけるときに使う。 このレコードはマスタKDCのポート464でなければならない。
_kerberos._tcp.quenya.org TCP経由でKDCサーバを見つけ るときに使う。このエントリはおのおののKDCでポート88でなければならない。
_ldap._tcp.quenya.org PDC上でLDAPサービスを見つける のに使う。このレコードはPDCのためにポート389でなければならない。
_kpasswd._tcp.quenya.org ユーザパスワード変更を行う ことを許可するためにkpasswd
を探すときに使う。これはポート 464でなければならない。
_gc._tcp.quenya.org グローバル型ログサーバを探すとき に使う。これはポート3268でなければならない。
以下のレコードも、Windows ADS ドメインコントローラ上の重要なサービスを 探すために、Windowsドメインクライアントによって使われる。
_ldap._tcp.pdc._msdcs.quenya.org
_ldap.gc._msdcs.quenya.org
_ldap.default-first-site-name._sites.gc._msdcs.quenya.org
_ldap.{SecID}.domains._msdcs.quenya.org
_ldap._tcp.dc._msdcs.quenya.org
_kerberos._tcp.dc._msdcs.quenya.org
_ldap.default-first-site-name._sites.dc._msdcs.quenya.org
_kerberos.default-first-site-name._sites.dc._msdcs.queyna.org
SecID._msdcs.quenya.org
正しいDNSエントリの存在は以下を実行することによって検証できる:
root#
dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org;> DiG 9.2.2 > @frodo -t any _ldap._tcp.dc._msdcs.quenya.org;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2;; QUESTION SECTION:;_ldap._tcp.dc._msdcs.quenya.org. IN ANY;; ANSWER SECTION:_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org._ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org.;; ADDITIONAL SECTION:frodo.quenya.org. 3600 IN A 10.1.1.16noldor.quenya.org. 1200 IN A 10.1.1.17;; Query time: 0 msec;; SERVER: frodo#53(10.1.1.16);; WHEN: Wed Oct 7 14:39:31 2004;; MSG SIZE rcvd: 171
Microsoft WindowsマシンはそのNetBIOS名を起動時に登録する(すなわち、動作に対するおのおののサービスタイプのためのマシン名)。この名前登録の正確な方法は、Microsoft Windowsクライアント/サーバにWINSサーバアドレスが与えられているか否かか、LMHOSTS検索が有効になっているか否か、NetBIOS名の名前解決にDNSを使うかどうかか否か、あるいはその他によって決まる。
WINSサーバがない場合、名前検索と同様、すべての名前登録は、UDPブロードキャストによって行われる。これは、すべての名前とIPアドレスの一覧を用意するLMHOSTを使う以外、ローカルサブネット単位で分割した名前解決を行う。このような状態で、リモートのMicrosoft Windowsネットワークのブラウズリスト中にSambaサーバの名前を強制的に入れ込むことによる方法を提供する(remote announceを使って)。
WINSサーバを使う場合、Microsoft Windows蔵案とはWINSサーバにUDPユニキャストで名前を登録する。このようなパケットはルーティング出来、WINSはルーティングされたネットワークを超えて名前解決が出来る。
スタートアップ処理中、すでに存在していなければ、ローカルマスタブラウザ(LMB)の選定が起こる。おのおののNetBIOSネットワークで、ある1つのマシンがドメインマスタブラウザ(DMB)として機能するように選択される。このドメインブラウジングは、Microsoftセキュリティドメインコントロールとは何らの関係もない。その代わり、DMBは(WINSまたはLMHOSTを使って見つけた)おのおののLMBに接続する役割を行い、ブラウズリストの内容を交換する。このようにして、すべてのマスタブラウザは、結果として、ネットワーク上にあるすべてのマシンの完全な一覧を得ることになる。毎11から15分ごとに、どのマシンがマスタブラウザになるかという選択が行われる。使用される選択基準の性質により、最も大きなuptime、あるいは最も上位のプロトコルバージョン、あるいは、そのたの基準を持つものがDMBとして選択される。
WINSサーバが使われているとき、DMBはそのIPアドレスをドメインの名前とNetBIOS名前タイプ1B(すなわちDOMAIN<1B>)を使ってWINSサーバに登録する。WINSサーバを使うすべてのLMBも、ドメインの名前とNetBIOS名前タイプ1Dを使ってそのIPアドレスを登録する。タイプ1Bの名前はドメインセキュリティコンテキスト内であるサーバ1つだけに割り当てられ、たった1つのタイプ1Dの名前がおのおののネットワークセグメントで登録される。タイプ1Dの名前を登録したマシンは、そのマシンがいるネットワークセグメントにおける、ブラウズリストメンテナの権限を持つ。DMBはLMBから得られたブラウズリストを同期させることに責任がある。
ネットワークをブラウズしようとするクライアントは、このリストを使うが、有効なIPアドレスへの名前解決の有効性に依存する。
Any configuration that breaks name resolution and/or browsing intrinsics will annoy users because they willhave to put up with protracted inability to use the network services.
Sambaはsmb.conf
ファイル中にremote browse syncパラメータを使うことで、ルーティングされたネットワーク越しにブラウズリストの同期を強制的に行う機能をサポートしている。この機能のためにSambaはリモートネットワーク上のLMBに接続し、ブラウズリストの同期を要求する。これはルータによって分離された2つのネットワークを効果的に接続する。2つのリモートネットワークはブロードキャストベースの名前解決か、WINSベースの名前解決のどちらを使っても良いが、remote browse syncパラメータがブラウズリストの同期を提供するが、それは名前からアドレスへの解決とは異なることに注意する必要がある。別の言い方をすると、サブネット間のブラウジングをきちんと機能させるためには、名前解決メカニズムが提供されていることが基本であるということである。このメカニズムとはDNS、/etc/hosts
、あるいはその他である。
ネットワークが、NTドメインでない、ワークグループに属するマシンを含むサブネット間のブラウジングを設定するために、ある1つのSambaサーバをDMBにする必要がある(NTドメイン中では両方の役割を同じマシンが担うが、これはPDCとは違うと言うことに注意)。DMBの役割はワークグループ中に参加しているマシンがあるすべてのサブネット上のLMBからブラウズリストを収集することである。DMBとして設定されたマシンがないと、おのおののサブネットは分離された、他のサブネットのマシンを見ることができないワークグループとなってしまう。これが、ワークグループに対してサブネット間ブラウジングをさせるDMBの存在理由である。
ワークグループ環境で、DMBはSambaサーバでなければならず、ワークグループ名につき1つのDMBでなければならない。SambaサーバをDMBとして設定するためには、smb.conf
ファイル中の[global]
セクションに以下のオプションを記述する:
domain master = yes |
DMBはそれがいるサブネット上でのLMBであるべきである。これを達成するためには、smb.conf
ファイル中の[global]
セクション中に、ドメインマスタブラウザのsmb.confで示されるオプションを設定する:
次に、ワークグループに対するLMBとして振る舞うことが出来るマシンを、おのおののサブネットごとに存在するようにする。任意のWindows NT/200x/XPマシンはこれが出来、Windows 9x/Meマシン(しばしばリブートの必要があるため、この目的に使うのには適さないが)もできる。SambaサーバをLMBにするには、以下の、ローカルマスタブラウザのsmb.confで示されているように、smb.conf
ファイルの[global]
セクション中に以下のオプションを記述する。
おのおののサブネットごとに1つ以上のSambaサーバに対してこれを行わないこと。そうしないと、LMBになるための競合が発生してしまう。
local masterパラメータはSambaに、LMBとして機能するようにさせる。preferred masterは、nmbd
に対して起動時にブラウザ選択を強制的に実行するようにさせ、os levelパラメータは、Sambaが、ブラウザ選択に勝つために必要十分となる大きな値を設定する。
もしもLMBにしたいNTマシンがサブネット上にある場合、以下の、マスタブラウザにならないsmb.confで示されているように、smb.conf
ファイル中の[global]
セクション中に、以下のパラメータを設定して、SambaがLMBにならないようにする。
もしも、Windows NTドメインにSambaサーバを追加する場合、SambaサーバをDMBとして設定してはならない。既定値では、ドメインに対するWindows NT PDCはそのドメインに対するDMBでもある。WINSを使って、DMB NetBIOS名(DOMAIN
<1B>)をSambaサーバがPDCとして登録すると、ネットワークブラウジングは崩壊する。
Windows NT PDCを含んでいる以外のサブネットでは、Sambaサーバを説明しているようにLMBとして設定しても良い。SambaサーバをLMBにするためには、以下のローカルマスタブラウザにするためのsmb.confのように、smb.conf
ファイル中の[global]
セクション中に以下のオプションを設定する。
もしも、同じサブネット上のマシンとの間で選択作業を行いたいのであれば、os levelパラメータをより小さな値に設定しても良い。これを行うことで、LMBになり得る、動いているマシンの順番を調整することができる。より詳細については強制的にSambaをマスタにするを参照のこと。
もしもすべてのサブネット上でのドメインのメンバであるWindows NTマシンがあり、それが常時確実に動いているならば、以下で示される、マスタにブラウザにならないsmb.conf
のように、smb.conf
ファイル中の[global]
セクション中で以下のオプションを指定することで、Sambaがブラウザ選択をしなくなり、LMBに絶対にならないようにすることができる。
マスタブラウズになるマシンはブロードキャストを使った選択プロセスで決められる。各選択パケットには選択作業において、ホストがどのような優先項目(バイアス)を持つべきかを決定するための、たくさんのパラメータを含んでいる。既定値では、Sambaは、各Windowsサーバ又はクライアントについて、低い優先度を持ち結果として選択からは外れる。
Sambaを選択したい場合には、smb.conf
中のos levelグローバルオプションをより大きい数字に設定する。既定値では20である。34を使うと、他のすべてのシステム(他のSambaシステムを除く)との選択に勝つ。
os levelが2の場合はWindows for WorkgroupsとWindows 9x/Meに勝つが、Microsoft NT/200x サーバには勝てない。Microsoft Windows NT/200xサーバのドメインコントローラはレベル32を使う。os levelの最大値は255である。
もしも、起動時にSambaに選択を強制させたいならば、smb.conf
中のpreferred masterグローバルオプションをyes
に設定する。Sambaは優先マスタブラウザでない、他のポテンシャルマスタブラウザよりも若干の優位性を持つようになる。これは注意深く使うこと。そうしないと、同じローカルサブネット上でpreferred masterをyes
に設定した2つのホスト(Windows 9x/MeかNT/200x/XPかSamba)があった場合、LMBになるための強制的な選択が、定期的かつ継続的に発生してしまう。
もしも、SambaをDMBにしたいならば、ブロードキャストが届かない分離されたサブネット上のLMBでもない、LANまたはWAN全体のDMBにSambaがならないという理由で、preferred masterもyes
に設定することを推奨する。
2つのSambaサーバがドメイン用にDMBになるように試みることは出来る。最初のサーバはDMBになる。その他のすべてのサーバは5分ごとにDMBになるように試行する。それらは、すでに他のSambaサーバがDMBであることを見つけて失敗する。これは、現在動いているDMBが故障したときに、自動的な冗長性を提供する。ブラウザ選択のネットワークバンド幅のオーバヘッドは相対的に小さく、おおよそ1つの選択ごとかつ1つのマシンごとに4つのUDPパケットを要求する。最小のUDPパケットは576バイトである。
ドメインマスタブラウザは複数のサブネットのブラウザリストを集めることに責任があり、それゆえ、サブネット間でのブラウジングが可能になる。smb.conf
中にdomain master = yesを設定することで、Sambaをドメインマスタブラウザにすることが出来る。既定値では、ドメインマスタになる設定ではない。
SambaをNT/200xドメインと同じ名前を持つワークグループ向けのドメインマスタに設定してはならない。もしも、同じネットワーク上で同じ名前を持つWindows NT/200xドメインと同じワークグループ名用にドメインマスタとしてSambaを設定すると、ネットワークブラウジングの問題が確実に発生する。
Sambaがドメインマスタでマスタブラウザの場合、他のサブネット上のLMBからのマスタアナウンスをリッスンし(おおよそ12分間隔)、ブラウザリストの同期を行うために、そのマシンに接続する。
Sambaをドメインマスタにしたい場合、選択に勝つために、os levelを十分に大きな値にすべきであり、preferred masterをyes
にし、起動時にSambaに強制的に選択を行わせるようにする。
(Sambaを含む)すべてのサーバとクライアントは、NetBIOS名を解決するためにWINSサーバを使うべきである。もしもクライアントがNetBIOS名を解決するためにブロードキャストのみを使うと、以下の2つが発生する:
LMBはWINSサーバに接続し、SambaがDMBである間はWINSサーバに登録を行い、 LMBはDMBとしてSambaのIPアドレスを受け取る。
クライアントがドメイン全体のブラウズリストを入手し、ユーザがそのリスト 中のホストに接続しようとしたとき、そのホストに対するNetBIOS名を解決する ために、WINSサーバに接続する。同じWINSサーバにホストのNetBIOS名が登録さ れている間はそのホストを認識することが出来る。
ゼロベースのブロードキャストアドレスをネットワークが使っている場合(たとえば、0で終わる)、問題が発生する。Windows fore Workgroupはゼロベースのブロードキャストをサポートしていないようなので、ブラウジングと名前検索が動かないだろう。
Sambaは複数のネットワークインタフェースをサポートする。もしも複数のインタフェースがある場合、smb.conf
中のinterfacesオプションを使って設定を行う必要がある。たとえば、eth0
,eth1
,eth2
, eth3
という4つのネットワークインタフェースを持つマシンがあり、eth1
とeth4
のみSambaが使う場合があったとする。この場合、この意図に合わせるようにするためには、smb.conf
ファイル中に以下のエントリを記述する:
interfaces = eth1, eth4 |
bind interfaces only = Yes |
bind interfaces only = Yesは指定されていないインタフェース上でTCP/IPセッションサービス(ポート135,139と445)を含めない時に必要である。nmbd
はリストされていないポート上でのUDPポート137から来るパケットをリッスンするが、それには返答しないことに気がつくこと。しかしながら、リストされていないインタフェース上でブロードキャストパケットは送信する。完全にイーサネットインタフェースを分離するには、Sambaサーバがアクセスできないようにしなければならないすべてのネットワークインタフェース上で、ポート137と138(UDP)、ポート135、139と445(TCP)をファイアウォール上でブロックすることが必要である。
smb.conf
中のremote announceパラメータはネットワーク上のすべてのNetBIOS名がリモートネットワークにアナウンスされることを保証するために使うことが出来る。remote announceパラメータの文法は以下の通り:
remote announce = 192.168.12.23 [172.16.21.255] ... |
or
remote announce = 192.168.12.23/MIDEARTH [172.16.21.255/ELVINDORF] ... |
ここで:
192.168.12.23
and 172.16.21.255
はリモートネットワークのLMBのIPアドレスか、ブロードキャストアド レスである。これは、LMBが192.168.1.23か、ネットマスクが24ビット (255.255.255.0)であるときに172.16.21.255として与えられる。 リモートアナウンスがリモートネットワークのブロードキャストに対 して行われるとき、各ホストはこのアナウンスを受け取る。これはノイズであり、 好ましくないが、もしもリモートLMBのIPアドレスが分からないときには必要である。
ワークグループ
はオプションで、自ワークグループかリモートネッ トワークのワークグループを指定できる。リモートのネットワークの ワークグループ名を使う場合、自マシンのNetBIOS名はそのネット ワークに所属するように見えるようになる。これは名前解決問題 を引き起こしかねず、避けるべきである。
smb.conf
のremote browse syncパラメータは手元のSamba LMBとの間で同期を取らなければならない他のLMBへアナウンスを行うのに使用する。これは、そのネットワークセグメント上でSambaサーバがが同時にLMBの時にのみ動作する。
remote browse syncパラメータの文法は以下の通り:
ここで、192.168.10.40
は、リモートのLMBのIPアドレスか、リモートセグメントのネットワークブロードキャストアドレスである。
WINSの使用(Samba WINS又はWindows NTサーバWINS)は強く推奨する。各NetBIOSマシンは、有効なサービスのサービスタイプの名前タイプの値と共に、名前を登録する。ユニーク名(タイプ0x03)として名前を直接登録する。また、LanManager互換のサーバサービス(他のユーザに対してファイル共有とプリンタ共有を提供する)が動いているときには、サーバ名(タイプ0x20)を登録することによりその名前も登録する。
すべてのNetBIOS名は最大15文字である。名前タイプの値が名前の後に付加され、合計16文字となる。15文字より小さい名前は15文字になるように空白が埋め込まれる。そのため、すべてのNetBIOS名は16文字(名前タイプ情報を含め)である。
WINは登録された16文字長の名前を格納できる。ネットワークにログオンしたいクライアントはNetLogonサービス名前タイプで登録されたすべての名前のリストをWINSサーバに問い合わせる。これはブロードキャストトラフィックを減少し、ログオン処理を高速化する。ネットワークセグメント越しにブロードキャストによる名前解決が出来ないため、このタイプの情報はWINSサーバがいないときに、すべてのクライアントが内包しなければならないlmhosts
ファイルを固定的に設定するか、WINSサーバによってのみ提供される。
WINSはすべてのLMBによってブラウズリストの同期を強制的に行う。LMBはDMBを使ってそのブラウズリストを同期し、WINSはそのDMBの識別をLMBに対して手助けする。定義によって、これは単一のワークグループ内でのみ動作する。DMBはMicrosoft NTドメインとして呼ばれているとは無関係であることに注意。DMBがブラウズリスト情報のみに関してマスタコントローラとしてDMBが言及する間、後者はセキュリティ環境について言及する。
WINSは、WINSサーバのためにすべてのTCP/IPプロトコルスタックが設定されている時のみ正しく動作する。あるクライアントがWINSサーバを使うように設定されておらず、ブロードキャストでの名前登録のみを引き続き使うようになっている場合、WINSはそれを認識できない。この場合、WINSサーバで名前登録を行わないマシンは、他のクライアントによる名前-アドレス変換が失敗し、それゆえ、ワークステーションへのアクセスエラーが発生する。
SambaをWINSサーバとして設定するためには、smb.conf
ファイルの[global]セクションで、wins support = yesを追加する。
SambaがWINSサーバに登録するためには、smb.conf
ファイルの[global]
セクションでwins server = 10.0.0.18を追加する。
特にその固有IPアドレスを指定して、wins support = yesと一緒に、wins server = 10.0.0.18を使わないこと。両者を同時にsmb.conf
で指定すると起動しなくなる!
SambaサーバまたはWindows NTサーバのどちらも、WINSサーバとして設定できる。SambaサーバをWINSサーバとして設定するためには、選択したサーバのsmb.conf
ファイルに以下を[global]
セクションに追加しなければならない:
wins support = yes |
Samba 1.9.17より前のバージョンでは、このパラメータは既定値でyesになっている。もしも、ネットワーク上で古いバージョンのSambaを使っている場合、最新のバージョンへのアップグレードを強く推奨する。そうしないと、それらすべてのマシンでこのパラメータを“no”に設定しなければならなくなる。
wins support = yesを設定したマシンは、登録されたすべてのNetBIOS名を保持し、NetBIOS名のためのDNSとして機能する。
単一のWINSサーバを設定することを強く推奨する。ネットワーク上で2つ以上のサーバに、wins support = yesを指定しないこと。
Windows NT/200xサーバをWINSサーバとして設定するためにはWINSサービスを設定する。詳細は、Windows NT/200xの説明書を参照のこと。Windows NT/200xのWINSサーバは、お互いに複製が出来、複雑なサブネット環境で2つ以上設定できる。Microsoftが複製プロトコルの開示を行っていないため、Sambaは現在それらの複製機能に参加できない。Samba間同士のWINS複製プロトコルは将来作成する予定だが、その場合、2つ以上のSambaマシンがWINSサーバとして設定できるようになる。現在は、1台のみのSambaサーバがwins support = yesと設定できる。
WINSサーバを設定後、ネットワークに参加しているすべてのマシンはこのWINSサーバのアドレスを設定するようにしなければならない。もしも、WINSサーバがSambaマシンならば、コントロールパネル->ネットワーク接続->ローカルエリア接続等->プロパティ->インターネットプロトコル(TCP/IP)->プロパティ->詳細設定->WINSダイアログ中のWINSアドレスフィールドにSambaマシンのIPアドレスを設定する(WindowsXPの場合)。SambaサーバにWINSサーバのIPアドレスを設定する場合には、すべてのsmb.conf
ファイルの[global]
セクションに以下を追加する:
wins server = <名前またはIPアドレス> |
ここで、<名前またはIPアドレス>は、WINSサーバのDNS名かそのIPアドレスである。
この行はSambaサーバ自身がWINSサーバとして動作する場合に、smb.conf
ファイル中に設定してはならない。もしもwins support = yesオプションとwins server = nmbd
は起動に失敗する。
サブネット間のブラウジングを設定するためには2つの方法がある。最初のもの詳細は、Windows NTドメインの一部としては設定されていない、Windows9x/Me、SambaとWindows NT/200xを含むネットワーク上でのサブネット間ブラウジングを設定するものである。2番目のものの詳細は、NTドメインを含むネットワーク上でのサブネット間ブラウジングを設定するものである。
Samba-3はWINS複製をサポートしていない。これを実装する試みはあり、wrepld
と呼ばれていたが、すでに開発は停止している。
一方、samba4WINS
というプロジェクトがあり、これは、Samba-3バージョン3.0.21から、Samba-4のWINSサーバを並列に動かせるようにするものである。samba4WINS
に付いての詳細は、http://ftp.sernet.de/pub/samba4WINSを参照のこと。
Samba WINSサーバに静的な円入折りを追加するのはとても簡単である。通常/usr/local/samba/var/locks
か /var/run/samba
にあるwins.dat
ファイルに行を追加するだけである。
wins.dat
中のエントリは以下の形式である:
"NAME#TYPE" TTL ADDRESS+ FLAGS
ここでNAMEはNetBIOS名、TYPEはNetBIOS名前タイプ、TTLはそのエントリの、秒単位の生存時間、ADDRESS+は登録したい1つ以上のアドレス、FLAGは登録時に使うNetBIOSフラグである。
nmbdを再起動するまで、wins.dat
への変更は反映されない。wins.dat
は動的に変更されるので、nmbdはこのファイルを変更する前に停止しておかなければならないことに注意。このファイルを編集後、nmbdを再起動するのを忘れないこと。
通常の動的エントリは以下のようになる:
"MADMAN#03" 1155298378 192.168.1.2 66R
NetBIOS名を静的に(恒久的に)するためには、以下のように、単純にTTLを0にする:
"MADMAN#03" 0 192.168.1.2 66R
NetBIOSフラグは16進数で、ビット単位に意味を持つ: 00 - Bノードの登録、20 - Pノードの登録、40 - Mノードの登録、60 - Hノードの登録、02 - 恒久名、04 - アクティブ名、80 - グループ名 である。'R'は登録レコードであることを表示する。そのため、 66Rはハイブリッドノードで、アクティブで、恒久的なNetBIOS名であることを意味する。これらの値は、Sambaソースコードリポジトリのnameserv.h
で定義されている。それらはNBフラグのための値である。
初期のSamba-3バージョンから、この方法は動作するが、WINS複製機能が追加された、将来のバージョンでは変更の可能性がある。
多くのネットワーク管理者がつまずく点なので、以下のヒントは十分に検討する必要がある。
Microsoft Windowsマシン上で2つ以上のプロトコルをインストールした場合、よくあるブラウジングの問題が発生する。
2つ以上のプロトコルをMicrosoft Windowsクライアントでは使わない。
すべてのNetBIOSマシンは15分間隔のLMB(とDMB)の選択プロセスに参加する。複数の選択基準がこの選択プロセスでの決定の順番を決めるのに使われる。動作しているSambaまたはWindows NTは優先順位が変更されていて、そのため、最も適したマシンが予想通り決定に勝ち、この役割を保持する。
選択プロセスはすべてのNetBIOSネットワークインタフェースで、いわば、最後まで行われる。TCP/IPとIPXがインストールされ、NetBIOSが両方のプロトコルで有効なWindows 9x/Meマシンの場合、選択は両方のプロトコル上で行われる。しばしば発生するが、もし、Windows 9x/Meマシンが両方のプロトコルを持つ唯一のマシンならば、LMBはIPXプロトコル上でのNetBIOSインタフェース上で勝つ。Sambaは、Windows 9x/Meが、LMBがどのマシンかということを知っていると主張することによって、LMBでなくなる。SambaはLMB機能をやめるため、すべてのTCP/IPのみで動くマシンのブラウズリスト操作はそのために失敗する。
Windows 95、98、98SEとMeは一般的に Windows9x/Meと言われる。Windows NT4、200xとXPは共通のプロトコルを使う。これらはざっとWindows NTファミリと言われるが、2000と XP/2003は、Microsoft Windows NT4とは異なる動作をする新しい拡張プロトコルを導入したと認識されねばならない。一般的に、サーバはより新しいか拡張プロトコルをサポートせず、NT4プロトコルで処理をするようになる。
最も安全な、従うべきルールのすべては単一のプロトコルを使う! である。
NetBIOS名からIPアドレスへの名前解決は、いくつもの方式を使って行われる。NetBIOS名前タイプ情報を提供可能なものは以下の通り:
WINS 最適の方法。
LMHOSTS 静的でメンテナンスしづらい。
Broadcast UDPを使うが他セグメントの名前を解決できない。
名前解決の別の意味は以下を含む:
Static /etc/hosts
メンテナンスしづらく、名前タイプ情報が欠落している。
DNS は良い選択肢だが、基本的なNetBIOS名前タイプ情報が欠落している。
ブロードキャスト名前解決のトラフィックを防ぐこととDNS検索の制限をしたいと考えているサイトが多数ある。name resolve order
パラメータはこれをとても助ける。name resolve order
パラメータの文法は以下の通り:
name resolve order = wins lmhosts bcast host |
or
name resolve order = wins lmhosts (bcastとhostを省略) |
既定値は:
name resolve order = host lmhost wins bcast |
ここで、“host”は、UNIXシステムに実装されているgethostbyname()呼び出しを使う方法である。これは、通常/etc/host.conf
、/etc/nsswitch.conf
と/etc/resolv.conf
によって制御される。
SMBネットワークは、browse listと呼ばれるネットワーク中のマシンのリストにクライアントがアクセスできる機能を提供するメカニズムである。このリストには、ネットワーク中の他のマシンに対してファイルまたは印刷サービスを提供するマシンを含んでいる。サーバの機能を現在提供出来ない他のマシンは含んでいない。ブラウズリストはすべてのSMBクライアントによって頻繁に使われる。SMBブラウジングの設定はある種のSambaユーザには問題があり、そのためにこの文書?????Configuration of SMBbrowsing has been problematic for some Samba users, hence thisdocument.
Microsoft Windows 2000とその後継バージョン、Samba-3とその後継バージョンは、NetBIOS over TCP/IPを使わないように構成できる。この方法で構成した場合、(DNS/LDAP/ADSでの)名前解決を正しく設定して動くようにしておくことは必定である。SMBマシン名からIPアドレスへの名前解決が正しく機能しない場合、ブラウジングは動作しない。
NetBIOS over TCP/IPが有効な時、WINSサーバを使うことは、NetBIOS(SMB)名からIPアドレスへの名前解決を支援するために強く推奨される。名前解決の他のどの手段でも提供出来ない、リモートセグメントクライアントのNetBIOS名前タイプ情報を提供することがWINSでは出来る。
Sambaはブラウジングを容易にする。ブラウジングはnmbdでサポートされて、smb.conf
ファイル中のオプションで制御される。SambaはワークグループのLMBとして動作でき、ドメインログオンとスクリプト機能をサポートする能力を現在持っている。
SambaはワークグループのDMBとしても動作する。これは、LMBからのリストを広範囲のネットワークサーバリストに集めることを意味する。このリスト中にある名前をブラウズクライアントが解決するために、Sambaとクライアント両方がWINSサーバを使うことを推奨する。
NTドメインにおいて同じ名前を持つ、ワークグループのドメインマスタに設定してはならない。各ワイドエリアネットワークで、それがNTかSambaか、あるいはこのサービスを提供する他のタイプのドメインマスタに関わらず、ワークグループ毎に一つのみのDMBを設定するようにしなければならない。
nmbd
はWINSサーバとして設定できるが、特段、SambaをWINSサーバとして使用することは必要ない。Microsoft Windows NT4、Microsoft Windows Server又は Advanced Server 200xをWINSサーバとして設定できる。WAN上でのNT/200xとSambaの混在環境では、Microsoft WINSサーバの能力を使うことを推奨する。Sambaのみの環境では、ある1つのSambaサーバをWINSサーバとして使うことを推奨する。
ブラウジングを機能させるために、nmbd
を通常どおり動作させるが、どのワークグループにSambaが属するかを制御する、smb.conf
中のworkgroupオプションを使わなければならない。
Sambaは他のサブネット上のブラウジングのために、それ自身を提供するために便利なオプションも持っている。このオプションは“通常でない”使い方のためにのみ使うことを推奨する。例をあげると、インターネット越しの通知である。smb.conf
マニュアルページのremote announceを参照のこと。
もしもうまく動かない場合、問題を把握するためにlog.nmbd
ファイルが役に立つ。問題を発見するために、log levelを2または3にしてみる。現在のブラウズリストはbrowse.dat
というファイル中に、テキスト形式で格納されていることにも注意。
もしもうまく動かない場合、ファイルマネージャ
中でサーバ名を\\SERVER
という形で入力することが出来、enterを入力すると、ファイルマネージャ
は有効な共有の一覧を表示する。
[global]セクションでguest accountを有効なアカウントとして設定していないと、何人かはブラウジングに失敗する。共有を表示するためのIPC$接続は、guestで行われ、そのため、有効なguest accountを設定しておかなければならない。
IPC$
共有はすべてのSMB/CIFSクライアントで、サーバ上で有効なリソースのリストを得るために使われる。これは、SMB/CIFSサーバが、Windowsサーバに対してマイネットワーク経由でWindowsエクスプローラがリソースを閲覧するために使われる時の、共有とプリンタのリストの元になるものである。この時点で、クライアントは\\server\IPC$
リソースに接続を行う。共有をクリックすると、\\server\share
に接続する。
Microsoft Windows 2000とその後継(Sambaも)はIPC$共有に対する匿名(すなわちguest account)アクセスを無効に出来る。この場合、SMB/CIFSクライアントとして動作するMicrosoft Windows 2000/XP/2003マシンは、IPC$共有に問い合わせるために現在ログインしているユーザの名前を使う。Microsoft Windows 9x/Meはこれができず、サーバリソースをブラウズできない。
他の大きな問題はブロードキャストアドレス、ネットマスク、あるいはIPアドレスが間違っている場合(smb.conf
中でinterfacesを指定した場合)である。
Samba1.9.17(α1)のリリースから、Sambaはサブネット境界をまたがってのブラウズリストの複製をサポートしてきた。この節ではどのようにこの機能を異なった設定中で設定するかを説明する。
TCP/IPサブネットをまたがったブラウズリストを見るために(すなわち、ブロードキャストパケットが通らない、ルータによって分離されたネットワーク)、少なくとも1つのWINSサーバを設定する必要がある。WINSサーバはNetBIOS名のためのDNS都市的脳する。これは、WINSサーバに直接問い合わせを行う事によって、NetBIOS名からIPアドレスへの変換を可能にする。これは、WINSサーバマシンのポート137に直接UDPパケットを投げることで行われる。WINSサーバは、問い合わせたマシンからのUDPを使うことによって行われる、既定値のNetBIOSからIPアドレスへの変換の必要性を防ぐ。これは、ある1つのサブネットは、WINSサーバを使わないで他のサブネット上のマシンの名前を解決することができないということである。Sambaのハック、すなわちremote browse sync
とremote announce
はUDPのブロードキャストによる伝搬を防ぐ普通の制限をうまく乗り越えるようにできている。ハックは一般的な解ではなく、WINSがあるところでは使うべきではなく、最後の手段として考えるべきである。
ネットワーク越えのブラウジングを正しく動かすために、すべてのマシン、すなわち、Windows95、WindowsNTあるいはSambaサーバはDHCPサーバ経由かあるいは手動で、WINSサーバのIPアドレスを設定する必要があることを思い出してほしい:Windows 9x/MeとWindows NT/200x/XPでは、これはネットワーク設定配下のTCP/IPプロパティ中にあり、Sambaではsmb.conf
ファイル中にある。
NetBIOS over TCP/IPなしでSamba-3を動作させることは可能である。もしも、これを行う場合、Microsoft ADSの外側で使うと、これは、ネットワークブラウジングサポートをやめることになると警告される。ADSは、すべてのSambaサーバのために適切なDNSレコードが挿入されるDNSを経由してブラウジングをサポートしている。
サブネット間のブラウジングはとても複雑で、多数の動いている部分を含んでいる。正確に動くコードが出来るまで、Microsoftは数年掛けることになり、Sambaはそれから数年遅れて追いついている。設定が正しければ、Sambaはサブネット間のブラウジングが出来る機能がある。
サブネット間ブラウジングの例のようなネットワーク設定を考えてみることにする。
これは、2つのルータ(R1,R2)で接続されている3つのサブネット(1,2,3)から成り立ち、それらはブロードキャストが届かない。サブネット1はその中に5つのマシンがあり、サブネット2は4つ、サブネット3は4つマシンがある。すべてのマシンは同じワークグループ名(単純にするために)に設定されている。サブネット1上のマシンN1-CはDMB(すなわち、ワークグループのブラウズリストを集める)として設定されている。マシンN2_DはWINSサーバとして設定されていて、すべての他のマシンはそのNetBIOS名をそこに登録している。
それらのマシンが起動するとき、3つのサブネット上それぞれで、マスタブラウザの選択作業が発生する。サブネット1上ではマシンN1_Cが選択され、サブネット2上ではN2_Bが、サブネット3上ではN3_Dが選択されると仮定する。それらのマシンはそのマシンがいるサブネット上ではLMBとなる。N1_CはそれがDMBとして設定されているために、サブネット1上のLMBとなる。
各3ネットワーク上で、共有サービスを提供するように設定されたマシンは、そのサービスを提供していることをブロードキャストする。各サブネット上のLMBはそのブロードキャストを受け取り、マシンがサービスを提供していることを記録する。この記録のリストはブラウズリストの基礎となるものである。この場合、すべてのマシンがサービスを提供するように設定されていることを仮定しているので、すべてのマシンがブラウズリスト上に載る。
各ネットワークで、そのネットワークのLMBは、ローカルブロードキャスト経由で受け取ったすべての名前を信頼できると考える。これは、ローカルブロードキャスト経由でのLMBで見えるマシンはローカルマスタブラウザとして同じネットワーク上にいなければならないという理由であり、そのため、信頼された、かつ検証可能なリソースである。ブラウズリストを収集する時に学習した他のネットワーク上のマシンは、LMBからは直接見えない。これらのレコードは信頼できない。
この時点で、ブラウズリストはブラウズリストの例1のようになる(それらはたった今特定のネットワーク上でネットワークコンピュータを見た時に見えるマシンである)。
Table 10.1. ブラウズリストの例1
サブネット | ブラウズマスタ | リスト |
---|---|---|
サブネット1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E |
サブネット2 | N2_B | N2_A, N2_B, N2_C, N2_D |
サブネット3 | N3_D | N3_A, N3_B, N3_C, N3_D |
この時点で、すべてのサブネットは分離され、任意のサブネットをまたいで見えるマシンはない。
次に、サブネットのブラウズの例2中のサブネット2を眺めてみよう。NB_2がLMBになると同時に、そのブラウズリストを同期するDMBを探す。これは、NetBIOS名 WORKGROUP<1B>に関連づけられているIPアドレスをWINSサーバ(N2_D)に問い合わせることによって行われる。この名前は、WINSサーバが起動するとすぐにDMB(N1_C)によって登録される。
N2_BがDMBのアドレスを知ると、DMBに対して、UDPのポート138を使って、マスタアナウンスパケットを送ることによって、サブネット2のLMBであることを告げる。次に、NetServerEnum2コールを行うことで、DMBとの同期作業を行う。これは、DMBが知っているすべてのサーバ名を送信元に送るようにさせる。DMBがマスタアナウンスパケットを受け取ると、そのパケットの送信者への同期要求をスケジュールする。両方の同期が終了すると、ブラウズリストは、サブネットのブラウズの例2中のようになる。
Table 10.2. サブネットブラウズの例2
サブネット | ブラウズマスタ | リスト |
---|---|---|
サブネット1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E,N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
サブネット2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*),N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
サブネット3 | N3_D | N3_A, N3_B, N3_C, N3_D |
サーバ名の後に(*)が付いたものは信頼されていない名前である。
この時点で、ユーザは、サブネット1または2上で両方のすべてのサーバを、ネットワークコンピュータで見ることができる。サブネット3上のユーザは引き続き自分がいるサブネット上のもののみが見える。
N2_Bで起きた同じ手順のイベントがサブネット3のLMB(N3_D)に対して起こる。DMB(N1_A)とブラウズリストの同期を行うと、サブネット1とサブネット2のサーバエントリを得る。N3_DがN1_Cと同期を取るとvica versa、ブラウズリストは サブネットのブラウズの例3のようになる。
Table 10.3. サブネットのブラウズの例3
サブネット | ブラウズマスタ | リスト |
---|---|---|
サブネット1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E,N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*) |
サブネット2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*),N1_B(*), N1_C(*), N1_D(*), N1_E(*) |
サブネット3 | N3_D | N3_A, N3_B, N3_C, N3_D, N1_A(*),N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*) |
サーバ名の後に(*)が付いたものは信頼されていない名前である。
この時点で、サブネット1または3上でのネットワークコンピュータでは、サブネット2上のユーザが引き続きサブネット1と2上のサーバのみが見え、3が見えないのに対し、すべてのサブネット上のサーバを見る事ができる。
最後に、サブネット2のLMB(N2_B)は再度DMB(N1_C)と同期をとり、抜けていたサーバエントリを受け取る。最終的に、定常状態(1台もマシンが削除されず、停止もしていない状態)になると、ブラウズリストはサブネットのブラウズの例4のようになる。
Table 10.4. サブネットのブラウズの例4
サブネット | ブラウズマスタ | リスト |
---|---|---|
サブネット1 | N1_C | N1_A, N1_B, N1_C, N1_D, N1_E,N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*),N3_C(*), N3_D(*) |
サブネット2 | N2_B | N2_A, N2_B, N2_C, N2_D, N1_A(*),N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*),N3_C(*), N3_D(*) |
サブネット3 | N3_D | N3_A, N3_B, N3_C, N3_D, N1_A(*),N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*),N2_C(*), N2_D(*) |
サーバ名の後に(*)が付いたものは信頼されていない名前である。
DMBとLMBの同期は引き続き行われるが、これは定常状態の操作として行われる。Synchronizations between the DMB and LMBswill continue to occur, but this should remain asteady-state operation.
もしもルータR1かR2が故障した場合、以下のことが発生する:
ブラウジングに関する質問は数多くメーリングリスト上に投稿される。ブラウジングに関する大多数の問題は、NetBIOS名前解決の間違った設定に起因するものである。ただ、いくつかは特に注目に値する。
Sambaを再起動しないでSambaのNetBIOS名前キャッシュをフラッシュする方法はあるか?
Sambaのnmbd
プロセスはすべてのブラウザリストハンドリングを制御する。通常の環境では、nmbd
の再起動に問題はない。これはSambaのNetBIOS名キャッシュをフラッシュする効果があり、再構築を行う。これは、異常なマシン名は再度ブラウズリストに現れないということが確実になるわけではない。nmbd
がサービスを停止後、ネットワーク上の他のマシンがブラウズマスタになる。この新しいリスト中には異常なエントリがそのまま含まれるかもしれない。もしもリストから異常なマシンを消したいのならば、ネットワーク上のすべてのマシンをシャットダウンし、すべてのマシンが停止後に再起動しなければならない。完全な再起動に失敗すると、唯一出来る他のことは、エントリがタイムアウトするまで待ち、その後リストからフラッシュされる。これは、ある種のネットワークでは長い時間(月単位)かかる。
“あるクライアントは"‘This server is not configured to list shared resources."と報告した。’”
おそらく何らかの理由でゲストアカウントが無効になっている。Sambaはsmbd
でブラウジングするためにゲストアカウントを使う。ゲストアカウントが有効か確認する。
smb.conf
マニュアルページのguest accountも参照のこと。
LMBがない。nmbdを設定するか、他のマシンでLMBを立てる。
LMBマシンにログオンできない。 ゲストユーザでログオンできるか?
LMBに対してIPレベルで接続できない。 ブロードキャストで到達可能か?
“テストネットワークに2台だけマシンがあったとする。1つはSambaサーバで他はWindows XPマシンである。認証とログオンは正常に動作するが、Sambaサーバ上の共有を表示させようとするとWindows XPクライアントは反応がなくなる。時々、数分反応がなくなる。最終的にはWindowsエクスプローラは反応して問題なくファイルとディレクトリを表示する。”
“しかし、共有はコマンドシェル(cmd
)でDOSコマンドを使うとすぐに使える。これはSambaの問題か、それともWindowsの問題か?この問題の解決方法は?”
いくつかの可能性がある:
最も一般的な、不完全なハードウェアの問題は、低コストまたは不完全なハブ、 ルータ、ネットワークインタフェース(NIC)と良くないケーブルに集中する。 もしも、ハードウェアの1部分が不良だと、ネットワーク全体が被害を受ける かもしれない。悪いハードウェアはデータの喪失を引き起こす。ほとんどの ネットワークハードウェアの不良問題は見た目のネットワークトラフィックの 増大をもたらすがそれだけではない。
数多くのサイトで、同様のネットワークブラウジングが遅くなる問題が報告され、 WebClientサービスを停止すると、問題が出なくなることがわかっている。これは、 動けば簡単な解であるという理由で、確かに探求されるべきことで ある。
このタイプの問題は、あるクライアントがWINSサーバを使うように設定され て(それはTCP/IP設定で)、ネットワーク上にWINSサーバがない場合である。 言い換えると、WINSサーバがあり、Sambaがそれを使うように設定されて いない場合である。NetBIOS over TCP/IPを使う場合はWINSの使用は強く 推奨される。すべてのクライアントでNetBIOS over TCP/IPを無効にしている ならば、SambaはWINSサーバとして設定されるべきでも、それを使うように されるべきでもない。
もしも、NetBIOS over TCP/IPが無効になっているならば、Active Directory が使われ、DNSサーバが正しく設定されない。詳細な情報は、 DNSとActive Directory を参照のこと。
Microsoft Windowsクライアント(ワークステーションまたはサーバ)上での、存在しない共有あるいはサーバに対するキャッシュされた参照はそれらの共有に接続する際に、Microsoft Windowsエクスプローラが無反応になると言う現象を引き起こす。しばらく経つと(かなり長い時間だが)、タイムアウトになり、ブラウジングが通常通りになる。
この現象を除くために、腐ったキャッシュされた参照は取り除かれるべきである。これは自動的には起こらず、手動での作業が必要である。これはMicrosoft Windowsのデザインによるものであり、Sambaで変えることは出来ない。現時点で無効になっている、マイネットワーク内の共有またはサーバへの無効なショートカットを削除するためには、HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\
配下にあるWindows レジストリを編集する必要がある。エントリMountPoints2
(Windows XP以降、またはWindows 2000以前ではMountPoints
)を編集する。\\server\share
という名前(ここで'server'と'share'は存在しないサーバまたは共有を参照している)のすべてのキーを削除する。
存在しないネットワークリンクの削除はユーザ単位で行う必要がある。言い換えると、Microsoft Windowsエクスプローラ内でのマイネットワーク
中のショートカットは、右クリックして削除を選択することで削除できる。
Sambaのユーザは、Windows、SambaとNovellサーバのネットワークブラウジングに対して、これらの存在しない参照が、悪影響を及ぼすと報告している。これはSambaサーバに関連しない一般的な問題であると思われる。Sambaユーザは、Sambaが、時として人柱ツールとして見られていることがあるために、しばしばこれを経験するかもしれない。これは、異なった名前、異なった共有で何回かSambaサーバを再設定したり元に戻すことをユーザが行うことという事実の結果は、不完全(不正)なキャッシュされた共有参照が出来てしまうことを増大させてしまう。Windowsクライアントは、それらの参照を満了としないので、手動による削除を必要とする。
現在アクセスするディレクトリにいなくても、すべてのキャッシュされた参照を見にいくことを試みるので、ダイアログボックスのオープンは(たとえばWordやExcel)、一般的に反応がとても遅くなる。