要点
- 現在行っている製品開発の関係で、SAMBAをセットアップ。
- ところが、まさかのトラブルに、数日間ものあいだ、ハマってしまう。
- 解決のメドが立たず、次善の策を検討に入ったところで、予想もしない原因が判明。
現在、会社の企画室および海外企画室のジョブとして、Linux関連の製品開発を行っている。その作業の一貫で、予期しないSAMBAでのトラブルに遭遇した。
SAMBAというのは、いうまでもなくあのSAMBAである。というのは不親切な言い方なので少し説明すると、UNIX系のＯＳで、WindowsのSMBプロトコルに対応したサーバを立ち上げ、UNIXとWindows相互のネットワークアクセスを可能とするシステムおよびツール群である。具体的には、このSAMBAを利用することにより、Windowsからはネットワークコンピュータの機能によりUNIX、LinuxやFreeBSDのファイルシステム、プリンタにアクセスでき、逆にUNIX系ＯＳからもftp形式やマウントをしたりしてWindows 98/NT系のリソースにアクセスできる。このページを見に来てくれる人にはまず不要な説明でしょうけども。
私などは、世にPC-UNIXというすばらしいものがある以上、できるだけWindowsにかかわりたくない人間であるが、いかんせん、その占有率は支配的という以上のものがある。SAMBAのような存在は、LinuxなどUNIX系ＯＳの利便性と存在価値を、Linux側からも、Windows側からも大きく広げるものであることは事実である。実際、上記の企画製品もSAMBAの存在なしではありえない。
最近徐々に顕著になっているように、PC-UNIX、とりわけLinuxはMicrosoftをおびやかしはじめている。それゆえに、SAMBAの開発チームは、Microsoftからいろいろと不当な圧力を受けている。同時に彼らは、できの悪いWindows側の、たちの悪い多くのバグに悩まされ続けている。SAMBAの側は正しく動作しているのに、Windows側のSMBプロトコルのバグ群のせいで、うまく動かない場合が多いのである。
純粋に技術志向で考えたとき、これほどいらだたしいものもなかろうと思う。にもかかわらず、精力的に活動しているSAMBA開発チームには、私は心から敬服する。UNIXに関する深い知識と技術をを持ちながら、自ら貴重なボランティアリソースをWindowsにかかわる分野に注ぎこむなど、私にはとてもできないことだからだ。深い感謝なしにはいられない。
さて、ところで、そのSAMBAの設定で、思いもよらず深くハマってしまった。単に、パスワードなしでpublicに共有できる設定、要するにどのWindowsマシンからも見えて、アクセスもできるようにしたいだけだったのだが、それがどうもうまくいかない。
具体的には、設定したWORKGROUPは表示されるのだが、そこをクリックすると、「そのような共有名またはコンピュータ名はない」というようなエラーが生じる。要するに、NETBIOS名が表示されないのだ。
設定ファイルであるsmb.confの記述は案外難しく、コツがいるといわれているので、WEB設定ツールのSWATなども利用してみたが、うまくいかない。SWATでうまくいかない以上、マニュアルと首っ引きで可能なオプションの調整をしてみる。おかげで設定オプションについて従来の何倍もの知識を獲得することができた、というオマケはついたが、それでもうまくいかない。
社内で、同じ運用がうまくいっているLinux機の設定ファイルをもらい、調べてみるがどうも該当するようなパラメータはない。挙げ句の果てに、その設定ファイルをそのまま使ってテストしてみたが、それでもだめ。
SMBプロトコルの機能上、WORKGROUPが表示されるにもかかわらずそこに属するNETBIOS名(コンピュータの識別名)がとれないというような現象が起こることは、不思議なことではない。ただ、その原因がどうにも分からない。
ネットでいろいろ調べてみると、RedhatはＯＫだがVineだとうまくいかないことがある、とか、日本語パッチの当たったバージョンではアクセスがうまくいかないかも知れないのでその場合はメーリングリストにあげてほしい、とか、なんとなくそれらしい情報があるが、どれもコアの部分で原因もしくは解決策と見なせそうな事項は載っていない。
また、厄介なことに、まれにアクセスに成功する場合があるのである。あるいは、既に存在するWORKGROUP名を使用すると、NETBIOS名が見えるのである。さらに、エクスプローラのツールメニューから、直接パスを指定してマウントすることはできる。同様に、Linux機からのsmbclientによるアクセスも問題ない。
それだけをやっていたわけではないが、このうまくいかないSAMBAの設定トラブルは、三日にもわたり、いい加減まいってしまった。なによりも、うまくいく場合がある、というのに悩まされた。
かねてよりSMBプロトコルは無意味に複雑だとは聞いていたが、上記のようにWORKGROUP名を他のホストと合わせるとアクセス可能などというのは、通常のネットワークのアドレス解決構造からは想像しにくい。結局のところ、なんとなくだれかがアドレス解決のためのサーバであり、そうでなかったり、というような妙な仕様と優先付けルールがなせるわざのようであった。
ともかく、このままではらちがあかない。ディストリビューションのせいであるとすると、そっくりシステムの入れ替えが必要なので、非常に厄介であるが、直接パスでのマウントは可能である。とりあえずこの方法で逃げるようにしようか、とそろそろ弱気なことを考えていたとき、思わぬヒントが得られた。Linux、VMwareのWin98、ノートＰＣのWin98の三者のネットワーク設定を揃え、社内のＬＡＮにつないだところ、その三者間では問題なくアクセスできるのに、３台のうちどこからも、社内の他のホストが見えなくなったのである。
これだ！と直観した。あとは原因を徹底して探るだけである。
で、結論はまったく予想しないものだった。原因は、社内のネットワーク設定ポリシーにあったのだ。
社内では、管理グループの決定により、クラスＡのローカル用アドレス「10.XX.XX.XX」を使用している。いうまでもなく非グローバル用に認められているアドレスである。で、当然クラスＡだからネットマスクは255.0.0.0だと思い、いつも勝手にそう設定していた。ところがどっこい、実は255.255.0.0を使っていたのである。
もちろん、そうした運用はありだし、そのためのネットマスクである。しかし、実質的に単一ネットのみの社内で、わざわざそのような設定を選んでいるとは夢にも思わず、ごくごく常識的に、かつ自分勝手にこう設定してしまったいたのである。なぜ自分勝手かというと、管理グループからは、ちゃんとネットマスクが255.255.0.0であることが、なんの補足説明もなくアナウンスされていたからである。
この設定の間違いは、SMB以外のプロトコルにおいては、少なくとも会社の環境ではまったくなんの問題も生じてこなかった。だから余計に、そんなところにトラブルの原因があるとは予想していなかった。ただ、原因が分かってから考えてみれば、確かにブロードキャストを濫用するSMBプロトコルにおいては、ブロードキャストアドレスを変えてしまうネットマスクの間違いは、名前解決において問題を生じるわけである。また、WORKGROUPが一致する、ネットマスクの設定の正しいWindowsマシンがLAN上にあった場合、そのマシンを経由して名前解決が成功し、他のマシンからアクセスできたりするのである。
ともあれ、慣れとは恐ろしいと改めて思った。社内の他のすべてのマシンは、管理グループの指示した通りに設定していたわけである。すべての社員がその意味まで理解して設定したのかどうかについては甚だ怪しい(^^;;)が、現実問題として、社内で和を乱していたのは、唯一私のみであったわけである。内容によっては、会社のネットワークに迷惑をかけたかも知れないところだ。
基本忘るべからず、というお話でした。
Back Home