Samba QandA Author 奥山健一 Last Modified 2001/06/17 00:30:02 (Sun) QandA について ┌──────────────────────────────────────┐ │[ 管理番号: 000000000004 ] │ │ Q. QandA って何ですか? │ │ │ │A. │ │ Questions and Answers の略です。良く聞かれる質問や、予想される質問に対し│ │ てその答を用意してあります。 │ │ │ │ 誰かに質問したりする前に、なるべくここを確認するようにしましょう。ここに│ │ 載っているような質問をすると、怒られることがありますよ(^^;)。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000005 ] │ │ Q. QandA の入手先 │ │ この QandA はどうやったら手に入りますか? │ │ │ │A. │ │ │ │ に最新のものが置いてあります。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000006 ] │ │ Q. FAQ と QandA の違いは? │ │ FAQ というものを良く聞きますが、QandA との違いは? │ │ │ │A. QandA は想定問答集だと思えばいいです │ │ FAQ は Freqently Asked Questions の略です。 ML などで、繰り返し現れる質 │ │ 問に対する答を集めたもので、このため繰り返し現れない質問、まだ聞かれたこ│ │ とのない質問は FAQ には収集されないことがあります。 │ │ │ │ QandA はどちらかというと、想定問答集に近いです。 │ │ │ │ FAQ のように繰り返される質問に対する答はもちろん、まだ誰も行ったことのな│ │ い質問であっても、知識として保存しておいた方が良いと判断された場合は、 │ │ QandA はそれを取り込みます。 │ │ │ │ もっとも、FAQ も最近は QandA と何処が違うのか判らないぐらい予測される質 │ │ 問を予め準備しておくことがありますので、そんなに厳密に考えない方が良いで│ │ しょう。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000021 ] │ │ Q. QandA に新しい項目を追加するには? │ │ ある問題で突っ掛かってしまいました。結局解決したのですが、他にも同じ問題│ │ で引っ掛かる人がいるかも知れません。 QandA にしたいと思ったのですが、ど │ │ のようにすれば新規に登録してもらえますか? │ │ │ │A. 以下のルールに従ってください。 │ │ まず QandA を良く読んでください。もうすでに誰かが問題を解決していません │ │ か? 大丈夫ですね? ここでチェックしなかったせいで無駄骨を折っても誰も喜び│ │ も悲しみもしませんよ? │ │ │ │ QandA は GPL に従っています。あなたの提出した QandA は自動的に GPL に従 │ │ うことになります。それで構いませんか?構いませんね? │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ では、次に を獲得してください。ここには、QandA を作成するため │ │ のツールが一セット含まれています。この tarball を展開すると │ │ ./Samba-QandA │ │ +--> newfile/ │ │ +--> .index │ │ +--> RCS/ │ │ | +--> qa.merge,v │ │ | +--> template,v │ │ : : │ │ +--> bin/ │ │ : : │ │ +--> temp/ │ │ : : │ │ │ │ │ │ のようにディレクトリが展開されるはずです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ ./Samba-QandA ディレクトリに移動して、次のように実行してください。 │ │ % ./bin/newfile.perl │ │ Your new file exist as name ./newfile/000000000021.qa │ │ │ │ │ │ ファイル名は時々によって異なるでしょうが、 ./newfile の下に xxxxxx.qa の│ │ ようなファイル名ファイルが１つできました。このファイルをベースにQandA を│ │ 書いていきます。 │ │ │ │ 新しくつくられたファイルは次のような形をしているはずです。 │ │ # Samba QandA, Copyright (C) 2001 K. Okuyama │ │ # │ │ # This document is free software; you can redistribute it and/or │ │ # modify it under the terms of the GNU General Public License │ │ # as published by the Free Software Foundation; either version 2 │ │ # of the License, or (at your option) any later version. │ │ # │ │ # This program is distributed in the hope that it will be useful, │ │ # but WITHOUT ANY WARRANTY; without even the implied warranty of │ │ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the │ │ # GNU General Public License for more details. │ │ # │ │ # 日本語の場合、文字コードは EUC に統一してください。 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ まず Copyright を書き換えて、適切な日付と著者名に変更してください。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 適切な Question Title と Question Body を考えてください。 │ │ │ │ Question Title はごく短いタイトルで、質問を表すものです。これは1行に収ま│ │ る程度の文章に限定してください。 │ │ │ │ Question Body は質問を詳しく説明した文章です。とは言っても、あまりにも長│ │ いと質問が判らなくなりますので、加減は必要です。 │ │ │ │ Question Title を決めたら、 の間に書いてください。 │ │ │ │ ただし、Question Title に改行を含んでは行けません。 < から > までが全て1│ │ 行に収まらなくてはいけません。これはスクリプトを手抜きしたためです。が、│ │ 所詮この手の物は作った者勝ち。諦めていただきましょう。 │ │ │ │ 一方 Question Body は、 と の間に書きます。この中の記述│ │ ルールは通常の HTML の BODY 部に従います。ただし、いくつかルールを守る必│ │ 要があります。 │ │ │ │ まず、Question Body は HTML 4.01 Transition に従ってください。たとえば、│ │

は

とペアで使い、段落を表すものであって、決して改行を意味するも│ │ のではありません。これらの「意味」を厳密に守ってください。 │ │ │ │ Java Script などのスクリプト言語による記述は禁止します。理由の 98% は │ │ QandA のパーサーが対応していないから、ですが、残り 2% は様々な Webブラウ│ │ ザに対応したり、ページを機械に読んでもらって理解している人達のためです。│ │ │ │ 行頭が # で始まる行はコメント行です。最終的な QandA には反映されません。│ │ これとは別に HTML のコメント がありますが、優先順位は # の方│ │ にあります。ですので、 │ │ # This is comment for QandA. │ │ │ │ If it did, this line will be visible. │ │ &# --> This line will always be visible. │ │ │ │ │ │ というソースは │ │ This line will always be visible. │ │ │ │ │ │ としかなりません。 │ │ │ │ ソースコードの1行には、 HTML の命令タグか、文章か、 QandA 用のコマンドか│ │ 、どれか1つしか書かないでください。これも処理スクリプトの都合です。です │ │ ので、 │ │ This is example QBODY. │ │ │ │ │ │ │ │ のような書き方はしないでください。たとえブラウザで見たときにどんなに間抜│ │ けな空行が追加されていても、です。今のスクリプトが仮に、偶然にもあなたの│ │ 書いた書き方を処理できても、後で何らかの改造を施された後も処理できる保証│ │ がありません。一方で、間抜けな空行は基本的にはブラウザが間抜けだからであ│ │ って、今後改善される可能性が残っています。 │ │ │ │ さて、QBODY の中では、次のような特殊命令が使えます。 │ │ │ │ [管理番号: xxxxx] │ │ 他の QandA を参照する際に使います。一度登録された QandA の管理番号は│ │ 基本的に変化しません。このコマンドを使うと、 と で囲まれた範囲が│ │ 指定した管理番号へのリンカーにもなります。 │ │ │ │ 1つ注意すべきなのは、管理番号 00001 と管理番号 0000001 は異なる、と │ │ いう点です。管理番号は実際には「番号として」ではなく「文字列として」│ │ 処理されます。 │ │ │ │ │ │ 1行コマンドです。 の間に URL を指定すると、そこがそのまま│ │ アンカーとしても参照されるようになります。同じことを2度書く必要がな │ │ いのは便利です。 │ │ │ │ , │ │ スクリプトを書くときは、このコマンドで囲んでください。今の所 
  │
│        と
に置換される、以上の意味はありません。 │ │ │ │ ━━━━━━━━━━━━━━━━━ │ │ Question Title と Question Body を考えたように、答に対しても Answer │ │ Title と Answer Body を考えてください。 │ │ │ │ Answer Title は、答を一言で答えられた場合に書いてください。時と場合によ │ │ っては、無理な場合もありますので、これは必ずしも必要ではありません。 │ │ │ │ Answer Body は答の本文です。具体的であればあるほど、詳細であればあるほど│ │ 良いはずですが、だからといって不必要な事まで書く必要はありません。 │ │ │ │ の所に、Answer Title を書いてください。記述ルールは と│ │ 同じです。もし、Answer Title が無い場合も、 は消さないでくださ │ │ い。 │ │ │ │ と の間に Answer Body を記述してください。記述ルールは │ │ 、 と同じです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 場合によっては、どの様に見えるか試したい場合があるでしょう。この場合は、│ │ この新しいファイルを │ │ ./Samba-QandA/source/QAs/ │ │ │ │ │ │ の下にコピーしてください。その上で、 │ │ ./Samba-QandA/source/qa.merge │ │ │ │ │ │ ファイルの と で囲まれた中に │ │ │ │ include ./QAs/000000000004.qa │ │ include ./QAs/000000000021.qa │ │ │ │ │ │ │ │ のように適当に追加して下さい。その後、 │ │ % make clean │ │ % make │ │ │ │ │ │ とやると、 │ │ ./Samba-QandA/result/Samba-QandA.html │ │ │ │ │ │ というファイルができていると思います。これを適当なブラウザーなどで見れば│ │ 、結果を参照することができます。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 満足なできばえの QandA が完成したら、 Subject に [] という文字を書いて、│ │ までメールで送ってください。 │ │ │ │ ただし、いくつか注意事項があります。 │ │ │ │ 私の気分が載らないと、載らない。 │ │ この QandA は「私が好きなものをのせる」というすさまじい優先順位がつ │ │ いています。自分で書いておいて何ですが、誰か適当な人にとっとと引き継│ │ いでもらいたいものです。 │ │ 管理番号は改めて振り直します。 │ │ これはある意味当然の話で、作り始めたときに 35番でも、作り終わったと │ │ きには別の人が 35 番を取っている可能性があります。 │ │ 文面はかなり書き変わる危険性があります。 │ │ 文面も「気分」で決めていますので、当然この危険性があります。 │ │ 時には査読があり得ます。 │ │ なんか怪しい内容や逆に大事そうだが情報が足りていない場合、書き直して│ │ もらうことがあります。当然、採用に掛る時間は不明です。 │ │ 暇なときにしか更新されません。 │ │ 私がかなり暇になったときにしか、Samba-QandA は更新しません。 │ │ 受取りのメールはあったりなかったり。 │ │ これも「気分」です。諦めましょう。 │ │ │ │ こんな劣悪な条件で良いならば、もしかするとあなたの QandA は採用されるか │ │ も知れません。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000022 ] │ │ Q. この QandA システムを流用してもいいですか? │ │ この QandA システムを別の QandA を作るために使ってもいいですか? │ │A. どうぞ │ │ この QandA システム全体が GPL ですので、その条件下であれば自由に使ってく│ │ ださい。 │ │ │ │ ただし、使い方に関するドキュメントはありません。自力でスクリプトと │ │ Makefile を読んで、理解してください。 │ │ ./Samba-QandA/source/qa.merge │ │ │ │ │ │ というファイルに基本的な制御用の情報が、 │ │ ./Samba-QandA/source/QAs/ │ │ │ │ │ │ の下に、各 QandA のソースを置けば良いようにつくったはずですが…。 │ │ │ │ なお、使えないシステムだと判っても、私は知りません :p │ │ │ │ │ └──────────────────────────────────────┘ Client の設定などに関する話 Windows Client の種類・設定の違いなどの話。 ┌──────────────────────────────────────┐ │[ 管理番号: 000000000003 ] │ │ Q. Samba と相性の良い Windows OS │ │ Windows OS の種類によってパフォーマンスは違うのか? │ │ │ │A. 違います。それもかなり大幅に。 │ │ 一番端的に判るのは Windows NT と Windows 2000 の違いでしょう。 netbench │ │ 7.0 を使ってパフォーマンス測定を行った場合、全く同一の PC 上で動く │ │ Windows 2000 は、Windows NT の、おおよそ 1.5 倍の速度で通信できることが │ │ 観測できます。 │ │ │ │ 実は NT が発行する SMB message の3つに1つは SMB nttrans: IOCTL という種 │ │ 類のものです。このリクエストに対して Samba は not supported を返します。│ │ しかし、何度 not supported を返しても NT は 3つに1つはこのリクエストを発│ │ 行し続けます。しかし Windows 2000 はこの命令を発行しません。これ以外にも│ │ いくつもの命令が NT では効率悪く発行されており、 2000 ではそれに対する改│ │ 善がなされています。 │ │ │ │ また、TCP/IP packet の再送状況を見ていても、明らかに NT の方が 2000 に比│ │ べて再送が高頻度に発生します。 │ │ │ │ これらの要因が重なって 1.5 倍もの速度差を引き起こすのです。 │ │ │ │ 今の所これら以外についての正解は持ち合わせていません。従って、私が推奨で│ │ きるのは、 │ │ 「2000 でも NT でもいい場合は 2000 にしろ」 │ │ という事だけです。 95/98/98SE/ME の間にどの様な関係があるのか、私には判 │ │ らないし、 2000 や NT と比べてどれが効率が良いか、も判りません。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000007 ] │ │ Q. Samba と相性の良い PC は? │ │ PC を購入する場合、Samba と通信する上で考慮した方が良い点は? │ │ │ │A. │ │ 最近の PC はマザーボードに Ethernet Card などいろいろなものが標準装備さ │ │ れていたりしますので、その辺も含めて答えると、考慮するべき点は山のように│ │ あります。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ とりあえず、PC の CPU パワーはたくさんあればあるほど良いでしょう。 │ │ │ │ Samba は Windows からのリクエストを受けて動きます。しかも、人間が行う1つ│ │ の動作に対して複数のリクエストを順番に発行して、その処理を行います。この│ │ 時、 Windows はあるリクエストを Samba サーバーに投げたら、その結果が得ら│ │ れるまで次のリクエストを絶対投げません。 │ │ │ │ このため、Samba は十分に速く返答しているのだが、その返事をすばやく処理で│ │ きないために処理全体がもたもたする、という現象が起るとトータルのパフォー│ │ マンスが低下してしまいます。これを回避するには PC の CPU パワーはたくさ │ │ んあった方が良いわけです。 │ │ │ │ さらに言うならば、 CPU の処理能力が低いと、そもそも NIC カードを限界能力│ │ まで引き出してやることさえできません。これでは処理速度が上がるわけがあり│ │ ません。このような観点からも CPU の能力ははたっぷりあった方が良いのです │ │ 。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ メモリをけちるべきではありません。 128Mbyte ぐらいはどどん、と載せてあげ│ │ ましょう。 │ │ │ │ Windows ではメモリの総量が 64Mbyte 以下の場合、 Excel や Word などの │ │ Microsoft 製オフィススィートと呼ばれるソフトを使うとメモリが足りなくなる│ │ ことがよくあります。このため、これが発生すると disk 上に仮想空間を用意し│ │ て、ここにメモリのイメージを一部書き出しながら動作する、ページスワップと│ │ いう処理を開始します。 │ │ │ │ いかに昨今の HDD が速くなったとは言っても、所詮メモリの敵ではありません │ │ 。軽く1万倍以上の速度差がある以上、ページスワップが起動したら実行速度は │ │ 著しく落ちます。 │ │ │ │ 実は、Internet などのネットワーク通信は、通信するべきデータを格納してお │ │ く送受信バッファーが必要なので、通信しない場合に比べてメモリを要求します│ │ 。 Samba へのアクセスを要求したアプリケーションが Swap Out されていると │ │ 受信したデータをすばやく処理できないため、格納用のバッファーはますます多│ │ く必要になり、ますますメモリを圧迫します。 │ │ │ │ 残念ながら、Windows はこのような状態に陥った場合のメモリの利用方法が │ │ unix に比べて格段に劣っています。 Windows の場合、特定の利用目的用にメモ│ │ リを割り振ってしまったら、他の用途に融通し合う、という事ができない構造に│ │ なっているのです。ですので例えば │ │ 「disk cache 用のメモリがまだたっぷり余っている」 │ │ という場合でも、そのメモリを利用することなく Application 用のメモリを │ │ SwapOut してしまう、という現象を起します。 │ │ │ │ Word だけ、Excel だけ、というのであれば、 128Mbyte もあればこのような状 │ │ 態はほぼ確実になくせるでしょう。最初の 64Mbyte は Internet Explorer に、│ │ 次の 64Mbyte を Word にという概算です。 │ │ │ │ ただし、Word 文書の中に Excel の表を OLE の形で取り込む、などと言うこと │ │ を始めると、Word と Excel が同時に動き出しますので、 128Mbyte では足りま│ │ せん。こういう使い方をする場合は 256Mbyte ぐらいは欲しいでしょう。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ NIC カードも安物を買うべきではありません。また、通信速度も 100Mbps 未満 │ │ のものにするべきではありません。 │ │ │ │ とりあえず Ethernet で通信するもの、と仮定します。 Token Ring の場合など│ │ はそんな人自身が少ない上に、あまり選択肢もありませんので悩みようがないか│ │ らです。 [脚注 1] │ │ │ │ まず、最初に重要になるのは、 Ethernet Card、あるいは Mother board にのっ│ │ ている Ethernet Chip 上に存在する send buffer 並びに recv buffer のサイ │ │ ズです。 │ │ │ │ Ethernet Packet は、最大で全長 1518byte (正確には 1518オクテット、と呼 │ │ ぶ)になります。逆に言えば、最大 1518byte までは連続して飛んでくる可能性 │ │ があるわけです。もし、recv buffer のサイズが 1518 byte 未満の場合、受信 │ │ の真っ最中に Ethernet Chip は CPU に向かって │ │ 「データを吸い出してくれ」 │ │ とお願いしなくてはいけません。これが所定時間以内に始まらないと buffer が│ │ 足りなくなり、受信したビットを捨てるしかなくなってしまい、その Packet は│ │ 通信に失敗したことになってしまいます。が、はっきり言ってこんな Critical │ │ なタイミングでのアクセスを成功させるのはかなり難しく、結果、 Packet をロ│ │ ストする確率は非常に高くなるでしょう。 [脚注 2] │ │ │ │ 次に、ISA バス接続のカードや PCMCIA のカードでも 16bit bus モードでつな │ │ いでいるような古いカードは使うべきではありません。 CardBus のような │ │ 132MByte/sec(1056Mbps) で通信できるものを使うか、 PCI バス対応のネットワ│ │ ークカードを使うべきです。 │ │ │ │ 古いカードは bus 幅が狭く、そのためカードへのデータ転送や、カードからの │ │ データの吸出しに時間がかかります。古い PCMCIA の場合、最大転送能力は │ │ 20Mbyte/sec(160Mbps) しか出ません。これではタイミングが悪いと 100Mbps で│ │ 飛んできたデータをきちんと吸い出すことはできなくなる恐れがあります。 │ │ │ │ 例えばアプリケーションからのリクエストで、何らかの packet を送信しようと│ │ PC Card にデータを送信している最中に外部からデータがやってきて、しかも │ │ Ethernet Chip 上のバッファーが小さかった場合、ほぼ確実にその受信したデー│ │ タは失われてしまうでしょう。 │ │ │ │ Ethernet Card の中には send buffer/recv buffer とも通常の TCP/IP の受信 │ │ ウィンドウサイズである 8kbyte を遥かに上回るバッファーを用意しているもの│ │ があります。これを使うと、Winsock のバグなども回避できるので、 buffer サ│ │ イズは大きい方が良いでしょう。あるいは、自発的に DMA ができるものも良い │ │ でしょう。 │ │ │ │ 全二重通信対応のカードの方が通信効率は良くなりますから、全二重通信対応カ│ │ ードにするべきです。 │ │ │ │ 通信できるビットレートは最大のものを選ぶべきです。 10Mbps でも 100Mbps │ │ でも構わない場合は、100Mbps を選ぶべきでしょう。もし、光ファイバーなどで│ │ 1Gbps を使うことも可能な場合は、 1Gbps を選択すると、もっと良いでしょう │ │ 。通信速度の絶対値が速い、という条件が通信にとって不利になることはまずも│ │ ってありません。 │ │ │ │ ただし、通信速度が速くなればなるほど、到着したデータをすばやく処理し、新│ │ しくリクエストをすばやく生成する必要が出てきます。このために必要な CPU │ │ パワーとメモリはこれまた相応に必要になります。 [脚注 3] │ │ │ │ 実はこれらの条件をすべてチェックする必要はありません。安い・昔のカードほ│ │ どこれらの条件を満たしておらず、最近の・高機能なカードほどこれらの条件を│ │ 満たしている、という性質がこれらの商品ラインアップにあるからです。 │ │ │ │ ですので、 CardBus あるいは PCI で使う、 10/100 Mbps の両方に対応してい │ │ て、全二重対応の、なるべく新しい NIC を利用していれば良い、と言うことに │ │ なります。 │ │ │ │ 当然ですが、この NIC を使えない/使いこなせない PC は効率の悪い PC という│ │ 事でもあります。そのような PC でパフォーマンスを求めても、努力に対して成│ │ 果は上がりません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ だいたい、そんなことで悩むのは IBM の社員ぐらいだろう(^^;) │ │[脚注 2] │ │ 注意して欲しいのは、この様な現象が起っても別にそのカードは機能不全ではな│ │ い、と言うことです。デザインが悪いのは事実ですが、つないでいる計算機側が│ │ 適切にデバイスに応対してくれるなら十分な性能は出るわけですから。ある通信│ │ メディアで通信できることと、そのメディアの能力をフルに近く引き出すのは大│ │ きく違うことで、メーカーはフルに近く引き出すことなんか保証していないんで│ │ すよ。 │ │[脚注 3] │ │ 「金持ち全部持ってる」「貧乏人何も持ってない」の2状態しかない、というこ │ │ と。「中ぐらい」という半端な状態は投資対効果もあまり良くなく、お金の無駄│ │ でしかありません。これは計算機の関与するほとんどありとあらゆるものについ│ │ て言える事実です。 │ │ │ └──────────────────────────────────────┘ Server Server マシン、機種などに関する話 ┌──────────────────────────────────────┐ │[ 管理番号: 000000000008 ] │ │ Q. Samba を利用する上でお勧めの Server の条件は? │ │ │ │A. │ │ これは Client 以上に条件が沢山あります。とりあえず、unix あるいはそのク │ │ ローン OS でなくては動かない、という事は判った上での話をすることにします│ │ 。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000009 ] │ │ Q. 組み込みマシン用 OS で Samba は動きますか? │ │ VxWare や Phoenix OS など、組み込み OS の一部には unix 互換なインターフ │ │ ェースを歌うものがあります。これらの上で Samba は動きますか? │ │ │ │A. 本家の方で試した人がいたようですが無理でした │ │ unix clone ではあっても、ちゃんとプロセス毎に異なるメモリ空間を持ってい │ │ ない、一部の組み込みマシン用 OS は諦めましょう。 │ │ │ │ 一部の unix clone を歌う組み込みマシン用 OS は、プロセス毎のメモリ空間を│ │ 正しく掌握していません。あるプロセスが消費したメモリを解放するのは、その│ │ プロセス自身の仕事になっています。 │ │ │ │ 残念ながら、Samba はそのような OS 上で正常に動き続けられるほど、お行儀の│ │ 良いプログラムではありません。あるクライアントの相手をしていたプロセスが│ │ 終了する際、メモリを完全に自分で解放してから終了する、などという殊勝な作│ │ りにはなっていません。 │ │ │ │ また、まだまだメモリーリークなどのバグが残っていると予測されます。 │ │ │ │ 結果、しばらく(と言ってもどれぐらいかは状況依存ですが)使うとメモリ不足で│ │ 暴走を始める、などの現象が予測されます。 │ │ │ │ これは「仮想空間を持っている」だけでは駄目なので、それらの OS に仮想空間│ │ 対応モジュールを追加したら OK、と言うほど簡単に解決する問題でもありませ │ │ ん。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000010 ] │ │ Q. Server CPU の条件は? │ │ │ │A. CPU パワーが十分あるマシンを選びましょう。 │ │ まず最初に断っておきます。この問題は正確には OS とあまりにもタイトな関連│ │ 性があるので、実は厳密に言うとケースバイケースな例外が一杯あります。そこ│ │ で、ここでは OS とは Linux や FreeBSD などの、有名で Free な OS に限定す│ │ ることにします。 │ │ │ │ ここでいう CPU パワーとは SMP などで稼げるパワーとは若干違います。 SMP │ │ であればもちろん良いのですが、並列度が望むほど得られるとは予測しないこと│ │ です。それよりもむしろ、単一プロセッサーの演算速度を上げてください。 │ │ │ │ Samba という Server プログラムは、それ自身は文字列変換を行う時ぐらいしか│ │ CPU パワーを消費しません。しかし、network を監視し、directory 状態を毎回│ │ 参照し、 file data を読み書きする、というその動作の性質上、大量の system│ │ call を発行します。実はこの system call の大量発行が CPU パワーを大量に │ │ 消費するのです。 │ │ │ │ 例えば、 netbench などの benchmark test を使って、パフォーマンスを計測す│ │ るとします。当然パフォーマンスは Client の台数にしたがって徐々に延びてい│ │ くのですが、あるポイントでそれ以上延びなくなります。この上限に達した直後│ │ の CPU Usage を vmstat で見ると、 │ │ │ │ User System Idle │ │ 33 % 66 % 0 % │ │ │ │ のような数値になります [脚注 1] 。 Samba はかくも CPU を大量に要求するソ│ │ フトなんです。 │ │ │ │ SMP にすることによる効果は OS に依存して決定します。しかし、あまり期待は│ │ できません。 │ │ │ │ Samba は Client が増える度に smbd というプロセスを Client 用に 1つづつ増│ │ やしながら対応していきます。 SMP にすることで、この smbd プロセスを同時 │ │ に処理できる数は一気に CPU の台数分増えます。 │ │ │ │ しかし、すでに示したように、 CPU usage の 2/3 は kernel の中で消費されて│ │ います。そして、kernel の中の処理は、「全体で1つの作業」という整合性を保│ │ たなくてはいけないため、数多くの semaphore によるシリアライゼーション [ │ │ 脚注 2] が組み込まれています。 DiskIO/FileIO もその典型例ですし、NIC │ │ Control もその典型です。 │ │ │ │ もし、Disk IO や File IO, NIC Control のように外部デバイスが遅くて間に合│ │ わない、という状態であるならば CPU usage は 100% にはなりません。これは │ │ uni processor の段階でもそうのはずです。 │ │ │ │ 従って、CPU 自身が何らかの計算を行わなくてはいけない所で、 kernel がガン│ │ ガン動かなくてはいけなくて、なおかつシリアライズされた場所、がボトルネッ│ │ クになった瞬間から SMP はその効果を失います。つまり、ある一定時間以内に │ │ シリアライズされた計算の総計が、シリアライズされていない部分の時間の総計│ │ を上回った瞬間から、それ以上の CPU の追加は無意味になるのです。 │ │ │ │ より細かいグラニュアリティを持った制御や、 SMP を熟慮してどのデバイスを │ │ もどの CPU も制御できる、という性質を持った OS を利用すると、この限界ポ │ │ イントはかなりの高負荷をかけないと現れないでしょうが、 Linux や FreeBSD │ │ のように基本的には UniProcessor 用 OS の場合、やはりものには限度というも│ │ のがあり、そうなると CPU の台数を増やすよりも単体の絶対能力を向上させる │ │ 方が有利になるでしょう。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ 数値は概ね Linux 2.4.0 + 800MHz P-III での実測値と同じぐらいです。 │ │[脚注 2] │ │ ようするに「一度に１つしか処理できない」「誰かが処理していると、そこに踏│ │ み込んではいけない」状態にすること │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000011 ] │ │ Q. Server に載せるメモリの量は? │ │ │ │A. メモリは…適当に与えましょう │ │ unix の場合、Windows などと違って、メモリの用途はダイナミックに変更され │ │ ています。沢山 disk IO がある場合は、メモリの多くは file cache に使われ │ │ るでしょうし、プロセスが大量にメモリを要求すれば、 file cache は減ってプ│ │ ロセス空間が増えます。従って、OS が認識できる限り、メモリをいくら与えて │ │ も無駄になると言うことはありません。 │ │ │ │ Samba はそれ自体はさほどメモリを消費しません。しかし、Samba は、大量にデ│ │ ィレクトリ検索や inode 検索を要求します。ファイルシステムの構成が │ │ Windows と unix では異なるため、 Windows が一発で獲得できる情報を unix │ │ 上で獲得するには、 system call を何度も発行しなくてはいけないからです。 │ │ │ │ file system cache 用にメモリが大量にあると動作効率は向上します。この場合│ │ 、メモリの量は、基本的に Windows と共有している disk の容量に比例して大 │ │ きくする必要がある、と言えます。 │ │ │ │ 注意が必要なのは Samba Server マシンを NFS Server としても利用している場│ │ 合です。 NFS Server は Samba Server とは逆に、メモリを大量に消費するとい│ │ う特徴があります。このため、単一のマシンに Samba と NFS の両方の Server │ │ を兼用させる場合、 CPU パワーもメモリもたっぷりと与えるか、あるいは │ │ Client の数を相当に制限して公開している disk space を減らすか、どちらか │ │ をしないとパフォーマンスは覿面落ちていく結果になります。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000012 ] │ │ Q. Samba Server に適した OS は? │ │ │ │A. 実はこれが一番大事 │ │ 前にも述べましたが、 netbench を使って uni processor 時における CPU │ │ usage を vmstat で見ると、 │ │ │ │ User System Idle │ │ 33 % 66 % 0 % │ │ │ │ のような数値になります。が、 Linux 2.4.0 において、これをもっと Client │ │ の台数の少ない状態から計測していくと │ │ user が消費する CPU usage は Client の台数に比例して延びるのに対し、 │ │ kernel が消費する CPU usage はほぼ Client の台数の二乗に比例して延びる │ │ │ │ というそら恐ろしいことが判ります。 │ │ │ │ 仮に、 Client の台数を n とします。 user が消費する(つまり Samba server │ │ process 自体が消費する)演算能力は O(n) で増えていきます。 smbd というデ │ │ ーモンプロセスは基本的に Client 1台に対して、 1つづつ増えていくので、こ │ │ れは自然な現象です。一方 kernel が消費する(つまり Samba server が動いて │ │ いるために kernel が消費する)演算能力は O(n2) で増えていきます。結果、必│ │ 要となる総演算量は │ │ O(n2) + O(n) = O(n2+n) │ │ │ │ となります。この内 kernel が消費する演算能力の比率は、 │ │ │ │ O(n2) / (O(n2) + O(n)) = O( n2 / ( O(n2) + n ) ) │ │ = O( 1 / ( 1 + ( 1 / n )) │ │ │ │ となります。この式は、CPU usage が 100% になるまで有効であり、 CPU が強 │ │ 力であればあるほど、n の上限値は大きくなります。そして、 n が大きくなれ │ │ ばなるほど ( 1/n ) は 0 に近づき、結果、kernel が消費する CPU の演算量が│ │ 全演算量に占める割合は 100% に近づいていきます。 │ │ │ │ さらに、この式にはもう一つ楽しい事実が含まれています。 │ │ │ │ 全体の CPU usage は │ │ │ │ O(n2) + O(n) = O(n2) │ │ │ │ となります。ということは、CPU のパフォーマンスを2倍に増やしても、 n はそ│ │ の平方根、おおよそ 1.4倍にしかなりません。サーバー能力要求量がインフレー│ │ ションを起す、ということです。 │ │ │ │ この概算は、kernel の演算消費量が samba server process 自身の演算消費量 │ │ の成長率よりも速く上昇する限り、必ず似たり寄ったりの結果をもたらします。│ │ │ │ ということは、kernel がこの性質を持っている場合は、 Server が非常に非力 │ │ な CPU で動いているならば、 smbd/nmbd などのデーモンプロセスの効率はパフ│ │ ォーマンスに影響を与える事、逆に CPU のパフォーマンスが高い場合は優れた │ │ OS の選定こそがパフォーマンスに高い影響を与える事が判ります。 │ │ │ │ 実際に Server を用意し、各 OS をインストールしては、netbench などで1台づ│ │ つ client を増やしながら vmstat を使って、 CPU usage の負荷をかけている │ │ 最中の CPU usage の変化を計測することで、各 OS がどのような動特性を持っ │ │ ているのか計測することができます [脚注 1] 。逆に言えば、それ以外に適切な│ │ OS を選ぶ方法はありません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ Client の台数をとびとびにすると、間の値が正確に判らないのでどんな曲線で │ │ も当てはめられるようになってしまう。従って手を抜かずに1台づつ増やすこと │ │ をお勧めする。 │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000013 ] │ │ Q. Uni Processor で動作効率が良ければ SMP でも同じ OS で良い? │ │ uni processor で動作効率の良い OS がありました。 SMP にしても同じように │ │ 動作効率は良いでしょうか? │ │ │ │A. やってみなけりゃ判らない │ │ Uni processor で動作効率の良かった OS と言っても、効率が良かった理由は様│ │ 々あり得ます。 │ │ │ │ □ uni processor は「自分とのインターロック」をとる必要がないように作る│ │ ことができる。 RealTime 性を要求しなければしないほど、この傾向は強ま│ │ る。「インターロック」はグローバルなリソースである「実メモリ」への直│ │ 接のアクセスを必要とするので、結構遅い処理にならざるを得ないので、こ│ │ れが無くなると結構早くなる。 │ │ □ disk や ethernet card がそもそもすばらしく賢くて、 CPU はそこへ仕事 │ │ を投げつけているだけ。割り込みの頻度もごく稀にしか発生しない。 │ │ □ 実は小人さんが入っていて、一生懸命どうすると早くできるか考えている。│ │ │ │ これらの最適化の中には当然、 SMP にすると効率が落ちてしまう戦略もあり得 │ │ るでしょう。あるいは SMP にしても効率は変わらないかも知れません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ また、SMP にして、CPU を2つにすると効率が上がるが、 3つにしても2つの時と│ │ 同じである可能性もあり得ます。 │ │ │ │ unix の場合 user process 自体はほぼ確実に、複数の CPU によって並列に動作│ │ することができます。しかし、user process が system call を行ったり、周辺│ │ デバイスが割り込みを生じさせたりして kernel モードに入っている間には、リ│ │ ソースの排他的利用などを実装するために排他制御が必要になり、そこで『処理│ │ のシリアライズ』という現象が起ります。 │ │ │ │ 『処理のシリアライズ』というのはようするに、あるリソースを使わないと先に│ │ 進めないプログラムがリソースの利用権を求めて行列を作って待ってしまう、と│ │ いう現象です。この行列に並んでいない process は他の CPU によって先に進む│ │ ことができますが、この行列に並んでしまうと結局そこの部分だけは、たった一│ │ つの CPU で処理しているのと同じことになってしまいます。 │ │ │ │ もし、この『処理のシリアライズ』の部分が全体に占める割合がごく小さなもの│ │ であれば問題にはなりません。問題は例えば…uni processor の場合でも全体の│ │ 60% がこの『シリアライズ』された部分だった場合です。 │ │ │ │ SMP で CPU を2つに分割すると、この『シリアライズ』の部分よりも前は、従来│ │ の2倍の速度で処理されるようになるので、待ち行列に並ぶものの発生速度は従 │ │ 来の2倍になります。が、『シリアライズ』された部分は CPU が相変わらず1つ │ │ しか動けず、しかも速度は変わっていないので、早くなっていません。仮に『シ│ │ リアライズ』された部分は必ず CPU 1 番が処理していたとすると、 CPU 1 番が│ │ uni processor だった頃の 60% の部分を、 CPU 2 番が uni processor だった │ │ 頃の 40% の部分を処理することになります。見てくれはおおよそ2倍の処理能力│ │ を持ったように見えます。 │ │ │ │ しかし、CPU を 3台に増やしても、 2台だったときに CPU 2 番が処理していた │ │ 部分を CPU 2 と 3 で分担するだけで、 CPU 1 が処理していた『シリアライズ │ │ 』された部分は相変わらず複数分担できません [脚注 1] 。 │ │ │ │ 結果、2台の時は、処理時間は1台の時の 60% にまで減ったのに、 CPU を 3 台 │ │ にしても、1台の時の 60% のまま…という現象が発生してしまいます。 │ │ │ │ あるいは、シリアライズ部が 40% を占めていた場合は、 CPU 3台までは効果が │ │ あるが、4台目では効果がでない、という事になるでしょう。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ この問題はマイクロカーネルのジャンルでは結構研究が進んでいますが、マイク│ │ ロカーネルには「CPU が1台の時は相対的に遅い」「CPU が2台の時はマイクロカ│ │ ーネルじゃなくても同じぐらい早く見える」という難点があるので、低レベルス│ │ ペックマシン上の OS に採用しづらく、結果、スケーラビリティーの見えないま│ │ ま、不採用になることが多く、結果、なかなか良いマイクロカーネルOSが見当た│ │ らない、という状態に陥っています。 │ │ │ │ というわけで、今の所、『n台の CPU でそこそこ良い結果が得られた』からと言│ │ って、『n+1台の CPU でも良い結果が得られる』保証はありません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ というか、複数分担できないから『シリアライズ』するのであって… │ │ │ └──────────────────────────────────────┘ LAN Hub などに関する話 Install Install における Tips ┌──────────────────────────────────────┐ │[ 管理番号: 000000000023 ] │ │ Q. Samba インストール方法の種類 │ │ Samba をインストールする方法にはどのようなものがあるの？ │ │ │ │A. 大まかに言って3通りあります │ │ Samba は次の3通りのインストール方法が選べます。 │ │ │ │ □ Binary Package を使う │ │ □ Source Package を使う │ │ □ CVS で Source コードを持ってきて、ビルドする │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 「Binary Package を使う」方法は、 Binary Package がある OS を使っている │ │ ことが前提になります。 │ │ │ │ 例えば、RedHat Linux やその系統の場合、 RPM というバイナリパッケージがあ│ │ ります。また、FreeBSD の場合は「packages」というバイナリパッケージがああ│ │ ります。他にも、メーカー製の OS の場合も、それぞれバイナリパッケージがあ│ │ るでしょう。 │ │ │ │ これらの何かを使う場合は、基本的にできることは限られています。必要なバイ│ │ ナリパッケージを探しだし、それぞれのやり方に合わせてインストールする。そ│ │ れだけです。 │ │ │ │ このやり方には次のような利点・欠点があります。 │ │ │ │ 利点 │ │ 簡単 │ │ Binary Package をインストールしさえすれば、機種依存な問題はほぼ │ │ 解決されているでしょう。間違いなく敷居は低くなっています。 │ │ │ │ ただし、これは『誰にでもできる』という意味ではない。 │ │ │ │ Binary Package がやってくれるのは、実行用のバイナリファイルをつ │ │ くり、必要な設定ファイルなどをその OS に固有の置場所に置いてくれ│ │ る、それだけです。この事実は失念しやすく、思わず「誰でもできる」│ │ 事と勘違いしてしまいます。 │ │ │ │ 大抵の場合 uninstall もできる │ │ 大抵の Binary Package は、自分が何処に何を置いたのかを覚えていて│ │ くれます。インストールのために必要な依存関係をも含めて監視してく│ │ れて、適切に uninstall してくれる場合がほとんどです。 │ │ │ │ Source Code からインストールする場合、この機能はほとんど期待でき│ │ ません。 │ │ │ │ 余分なディスクを消費しない │ │ 小リソースなデバイスにインストールする場合、余分な(Source Code │ │ などの実行に直接関係のない) リソースを消費しない Binary Package │ │ でないとインストールすらままならないことはあり得ます。 │ │ │ │ また、コンパイラーなどをインストールする必要がない、という意味で│ │ もメリットがあります。 │ │ │ │ これは単にディスク容量だけでなく、セキュリティーの観点から見ても│ │ 重要な場合があります。不必要なコンパイラーが存在していると、それ│ │ を使って Cracking Tool をローカル環境でビルドするやからが出てく │ │ るかも知れないからです。 Cracker にほんの少しでも多くの自由を与 │ │ えるのは、得策ではありません。 │ │ │ │ 早い │ │ Source Code からインストールする場合、コンパイラーなどが Source │ │ Code をコンパイルする必要があります。 │ │ │ │ Binary Package では Package にすでに保存されているファイルを所定│ │ の場所にコピーするだけですので、依存関係のチェックに掛る時間とフ│ │ ァイルコピーに必要な時間ぐらいしかかかりません。 │ │ │ │ │ │ 欠点 │ │ Binary Package が存在しない世界では使えない。 │ │ 説明も何もないだろう。そりゃそういうものだ。 │ │ │ │ Binary Package を作った人の意図した場所にしかインストールされない │ │ Binary Package がファイルを設定してくれる場所は、あくまでも │ │ Package を作り上げた人が考えた場所だ。それが自然なのはその │ │ Package を作った人だけかも知れない。 │ │ │ │ 当然、それが自分の欲しいインストール形態と異なる場合、 Binary │ │ Package は使えないことになる。 │ │ │ │ Source Code はついてこない │ │ インストールしたパッケージが望み通りの挙動をしてくれるとは限らな│ │ い。大抵のソフトにはバグがあり、Samba と言えども例外ではない。と│ │ いうよりも Samba は Windows という「文書で規定されていない」事柄│ │ の多い作品をエミュレートする必要があるため、今でも数多くの問題が│ │ 発見されている。 │ │ │ │ この場合、Source Code なしで問題を特定したり、解消するのは難しい│ │ が、Binary Package は大抵の場合、ソースコードをインストールして │ │ くれない。 │ │ │ │ 必要な Package はないかもしれない │ │ Binary Package は Source code が完成した後、誰かが Binary │ │ Package を作って始めて使えるようになります。逆に言えば Source │ │ code が完成するまえに Binary Package が完成することはあり得ませ │ │ んし、 Source code が完成してすぐ Binary Package が完成するとは │ │ 限りません。 │ │ │ │ 従って、Source Code レベルで新しいバージョンが提供されたからと言│ │ って、 Binary Package も同じタイミングで提供されるとは限らないの│ │ です。この「遅れ」は、Security という観点からは致命的な場合があ │ │ り得ます。 │ │ │ │ │ │ ━━━━━━━━━━━━━━━━━ │ │ Source code package とは、たとえば、RPM における srpm や FreeBSD の │ │ ports のように、 Source code をその環境に合わせて fix、ビルドを行い、最 │ │ 終的に Binary Package を作成、場合によってはそのまま Binary Package のイ│ │ ンストールへと進む、パッケージを利用する方法です。 │ │ │ │ Binary Package を作成するために必要な手順は決まっていることが多く、また │ │ Binary Package を自動的に作成できると人手が省けることが多いので、多くの │ │ Binary Package は対応する Source code Package を持っています。 │ │ │ │ 利点 │ │ Binary Package の次ぐらいに簡単 │ │ Binary Package を自動的に生成し、それをさらにインストールするの │ │ が一般的なので、 Binary Package の場合に比べて手間が圧倒的に増え│ │ る、と言う事はない。 │ │ │ │ ただし、Binary Package を作成するための作業が Binary Package と │ │ 異なる場合があるので、 Binary Package をインストールできれば │ │ Source code Package もインストールできる、という意味ではない。 │ │ │ │ uninstall 可能である場合が多い │ │ install 作業自体は Binary Package と同じなので、 Binary Package │ │ に uninstall 機能がある場合は、 Source code Package にもあること│ │ が多い。 │ │ │ │ 自分の環境に適合したバイナリを作成できる │ │ 例えば一般的な i386.rpm は i386 以降の全ての intel CPU で動作す │ │ るようにコンパイルされています。 │ │ │ │ これは逆の言い方をすれば、Pentium4 を持っていても、 Pentium4 用 │ │ にチューンされたコードではなく、 i386 用のコードを実行していると│ │ 言う事で、 Pentium4 を最も効率よく使ってはいない、と言う事になり│ │ ます。 │ │ │ │ Source code Package はソースコードをコンパイルする所から制御でき│ │ るので、より効率の良いバイナリパッケージを作ることが可能だ、と言│ │ う事になります。 │ │ │ │ 複数の環境用のパッケージを作ることができる │ │ 大抵の場合、CPU などが異なっていても、同じ OS (RHL とか solaris │ │ とか)であれば、同じ Source code Package からバイナリパッケージを│ │ 生成できるものです。 │ │ │ │ ここで、自分が使っている環境の一部が、バイナリパッケージによるイ│ │ ンストールしか受け付けない場合でも、別のマシンにクロス開発用環境│ │ があれば、そこでバイナリパッケージを作成することができます。その│ │ 際に自分のマシン用にチューンしたバイナリパッケージも当然作成が可│ │ 能です。 │ │ │ │ もちろん、そのためには Source code Package の制御方法をより詳し │ │ く知らなくてはいけませんが、この結果得られるメリットには、手間を│ │ かける価値のあるものです。 │ │ │ │ 他の人のビルドの知識が使えるかも知れない │ │ Binary Package と違って、他の人が作った Source code Package を入│ │ 手できればそこには、その人がその Source code をその人の環境に適 │ │ 合させるために使った全ての技術が集約されています。 │ │ │ │ これらの知識は単に Source code からインストールしただけでは得ら │ │ れないし、もちろん、バイナリパッケージからは絶対に得られない知識│ │ です。 │ │ │ │ │ │ 欠点 │ │ Source code Package の無い世界では使えない │ │ ものによっては、Binary Package の作成方法を公開していない OS も │ │ あります。このような世界では Source code Package が存在せず、当 │ │ 然、結果として Source code Package は使えないことになります。 │ │ │ │ Source code Package をビルドするための知識が必要 │ │ Source code Package は Binary Package を作る環境でもあるので、当│ │ 然、Binary Package が自動的に行ってくれることを全て指示しなくて │ │ は行けません。 │ │ │ │ 時によっては Source code からそのままインストールするよりも手間 │ │ がかかる場合があります。 uninstall など、通常の Source code が持│ │ っていない機能も追加する必要があるからです。 │ │ │ │ 時間が掛る、リソースが多く必要 │ │ Source code からバイナリを作り上げ、それをインストールするのです│ │ から Binary Package に比べてインストールに時間が掛ります。 │ │ │ │ 当然 Source code を展開し、コンパイルするための CPU、ディスクス │ │ ペース、メモリなどが要求されます。ここには Source code から直接 │ │ ビルドするのに必要な全リソース + Source code Package を実行する │ │ ための (わずかとは言え) CPU, メモリ、ディスクスペースなどが必要 │ │ です。三つの方法の中では最もリソースが必要となります。 │ │ │ │ これらを提供できるシステムがないと、 Source code Package を使う │ │ ことはできません。 │ │ │ │ Source code を直接いじる場合に比べて柔軟性が少ない │ │ Source code Package はあくまでも「Package」です。信頼できる │ │ Package を作成するには、正しい(誰かが Cracking をしていない) │ │ Source code を入手する方法も提供しなくてはいけません。 │ │ │ │ これは逆に言えば Source code Package には、自分が相手にしている │ │ Source code はたった1種類しかないと言う事になります。それ以外の │ │ Package は正しく新しい Package なのか、誰かが Cracking を仕掛け │ │ たソースコードなのか、識別できないからです。 │ │ │ │ 通常の Source code であれば、正しい Source code を入手できた事さ│ │ え確認できれば、後は自分でどんなに変更しても全く障害は発生しませ│ │ ん。 │ │ │ │ Package の場合は「正しい Source code の獲得」と、「それに対する │ │ 変更」を全て「Package」の形で実装する必要があるので、場当たり的 │ │ な行動に出るわけには行きません。 │ │ │ │ これは細かい修正を繰り返す場合には極めて煩わしいもので、特に他人│ │ の Source code Package をベースにこの作業を行うのは悪夢になりま │ │ す。一度 Source code Package を完全に停止させ、自分の Patch を作│ │ 成しなくては行けないからです。 │ │ │ │ 最新の Source code 用の Source code Package はないかもしれない │ │ Source code Package があると、 Binary Package が作れます。という│ │ ことは、Binary Package ができる本の少し前に Source code Package │ │ はできあがる、と言う事です。 │ │ │ │ 当然、Source code が新しくなった直後には、 Source code package │ │ がありませんので、これができあがるのを待つか、自分で作る必要が出│ │ るでしょう。 │ │ │ │ このタイム・ラグは Binary Package と同様の問題を引き起こす可能性│ │ があります。 │ │ │ │ │ │ ━━━━━━━━━━━━━━━━━ │ │ 「CVS で Source コードを持ってきて、ビルドする」という方法は最も古典的な│ │ 方法です。 │ │ │ │ unix の free software では、昔から Source code は xxx.tar.gz という名前 │ │ のファイルにまとめた形で提供されてきました。あぁ、もちろん、圧縮方法は │ │ .gz ではなく .Z だった時代もありますし、圧縮されていなかった時代もありま│ │ すが。とにかく、最も古典的なソフトウェアのインストール方法は、ソースコー│ │ ドを獲得して、そこに書かれたインストール手法に従いビルドする、というもの│ │ でした。 │ │ │ │ この方法はこの最も古典的な方法を、ストレートに継承した方法です。唯一違う│ │ のは、ソースコードを獲得する方法が tar.gz ファイルをダウンロードするので│ │ はなく、CVS を利用する方法になっている点です。 │ │ │ │ 従来通りの tar.gz ファイルを獲得する、という方法ももちろん使えなくはあり│ │ ませんが、ほとんど推奨はできません。 │ │ │ │ Samba に限らず大抵のソフトウェアは、バージョンアップに際して小さな変更が│ │ 施されることがほとんどです。根幹的なプログラムの構造から作り直される可能│ │ 性はほとんどなく、それゆえにソースコード上の変更も小さいことが多いもので│ │ す。 │ │ │ │ 従来通りの tar.gz ファイルを獲得する方法の場合、バージョンアップの度に全│ │ ソースファイルを毎回獲得する必要があります。これは最初の1回はともかく、 │ │ 2度目以降に多大なネットワーク負荷が掛ってしまいます。 │ │ │ │ CVS はリビジョン管理システムです。 Samba も CVS で管理されており、 cvs │ │ の pserver 接続を用いて任意のバージョンを獲得することができるようになっ │ │ ています。これを使えば、2度目以降は1度目との差分情報だけを、 CVS システ │ │ ムが自動的に判断して送ってくるようになりますので、バージョンアップの際の│ │ 通信コストが圧倒的に少なくてすむようになります。 │ │ │ │ この CVS を使った方法の利点・欠点は次の通りです。 │ │ │ │ 利点 │ │ 任意のバージョンの Source が手にはいる │ │ CVS 管理されている範疇の、どのバージョンのソースコードでも自由に│ │ 入手可能です。当然最新のソースコードを入手することも可能です。 │ │ │ │ Binary Package として提供されていないものでも入手可能ですので、 │ │ パッケージを使う場合と異なりタイム・ラグがなく、 Security 上の問│ │ 題も発生しません。 │ │ │ │ 状況によっては、tar.gz ファイルにまとめられていない、ごく緊急に │ │ 作られたパッチなども入手できるでしょう。 │ │ │ │ トータルの通信量が少なくてすむ │ │ CVS は server 上にある各ファイルのバージョンを、手元のそれと比較│ │ して、要求されたリビジョンタグがついているものと異なる場合にのみ│ │ ファイル転送を行います。 │ │ │ │ 従って、tar.gz の場合のように全てを毎回ダウンロードする必要がな │ │ く、通信量的に効率的です。 │ │ │ │ ビルドのために必要な知識は、通常のソフトウェア開発と変わらない │ │ ソースコードからのビルドは、結局、通常のソフトウェア開発における│ │ バイナリビルドとなんら変わりません。 SRPM の場合と違って、これ以│ │ 上の知識を必要としません。 │ │ │ │ 任意の変更を自由に施せる │ │ ソースコードがあり、ビルド方法は自由なので、ソースコードを直接変│ │ 更するのはもちろん、バイナリの置場所なども自由に変更できます。 │ │ │ │ │ │ 欠点 │ │ uninstall など package を使っていればサポートされる機能が一切ない。 │ │ CVS を単純に使った場合、提供されるのはソースコードが提供している│ │ 機能そのままです。そして大抵の場合、Source code が提供する │ │ Makefile などには、 install 機能はあっても uninstall 機能はあり │ │ ません。 │ │ │ │ ディスクスペースなどをかなり消費する │ │ CVS の最大の欠点は、ソースコードが不要になってもソースコードを簡│ │ 単には消せない、と言う事です。そのソースコードは次のバージョンを│ │ 獲得する際に必要になるからです。さらに、CVS を利用すると小さなフ│ │ ァイルを沢山作るので、 inode などもかなり消費します。 │ │ │ │ ビルドのためには CPU も消費しますし、メモリも必要です。 │ │ │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000024 ] │ │ Q. お勧めの Install 方法は? │ │ │ │A. あなたのレベルと、管理するマシンの量依存 │ │ 最もお勧めの Install 方法は、 │ │ │ │ 1. CVS でソースコードを獲得して、 │ │ 2. ソースコードから binary package を作成し、 │ │ 3. binary package を使って必要なだけマシンにインストールする │ │ │ │ というもの。 │ │ │ │ もちろん、あなたの環境が悪くて CVS でソースコードを獲得できない場合はソ │ │ ースコードを tar-ball [脚注 1] で獲得するしかなかろうが、これは極力「環 │ │ 境をどうにかする」事をお勧めする。 │ │ │ │ あなたの管理するマシンが1台しかない場合、 binary package を作成せずに直 │ │ 接 install したくなるかもしれないが、これは極力避けた方が良い。標準的に │ │ サポートされている Makefile は確かに install はできるが、 uninstall がで│ │ きない。 │ │ │ │ 一方、あなたのレベルが低くて、ソースコードから binary package を作成でき│ │ ない場合、 binary package を持ってきて、これをインストールするしかない。│ │ 最初はこれしかないが、可能な限り早く、自分のレベルを向上させることをお勧│ │ めする。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ .tar.gz ファイルの事 │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000025 ] │ │ Q. CVS を使って Source code を獲得するには? │ │ CVS を使うのが良いのは判った。 CVS を使って Source code を獲得する方法を│ │ 教えてください。 │ │ │ │A. 次の手順に従う │ │ CVS を使って Source code を獲得するには、次の手順にしたがって作業を進め │ │ てください。 │ │ │ │ 次の条件を満しているものとします。これらの条件を満すためにどの様にすれば│ │ 良いのか、は環境依存です。環境依存な部分に関しては、残念ながら一般的指針│ │ はありません。 │ │ │ │ □ cvs がインストールされていること │ │ □ cvs が実行パスに含まれていること │ │ □ cvs で Internet へ接続できること │ │ □ Samba source code をダウンロードし、さらにそこでビルド等を行えるだけ│ │ のディスク容量 [脚注 1] │ │ □ そのディスク容量を使えるユーザーパーミッション │ │ │ │ さて、この上で、次の手順を踏んでください。 │ │ │ │ 1. │ │ ソースコードを持ってくるディレクトリを作成する。 │ │ cvs でソースコードを持ってくるためのディレクトリを作成します。 │ │ │ │ 厳密にはこれは必要ない場合が多いのですが、何かトラブルが起った際│ │ に、そのディレクトリごと全部消せば他に影響が出ない状態にするのは│ │ 、エラー回避という観点から重要です。 │ │ │ │ ここでは、/usr/local/src の下に samba というディレクトリを作るこ│ │ とにします。 │ │ % mkdir /usr/local/src/samba │ │ │ │ │ │ さらに、/usr/local/src/samba へ移動して、 /usr/local/src/samba │ │ をカレントディレクトリにします。 │ │ % cd /usr/local/src/samba │ │ │ │ │ │ │ │ 2. │ │ cvs でサーバーに login する。 │ │ cvs は cvs pserver へのアクセスに「login」という作業を必要としま│ │ す。 │ │ % cvs -d :pserver:cvs@cvs.samba.gr.jp:/project/cvs login │ │ │ │ │ │ password を聞かれると思いますので、cvs と答えてください。 │ │ │ │ │ │ 3. │ │ checkout を行う。 │ │ いよいよソースコードを獲得します。 │ │ % cvs -d :pserver:cvs@cvs.samba.gr.jp:/project/cvs co samba-ja │ │ │ │ │ │ この作業をスタートすると、結構時間がかかります。 │ │ │ │ もし、電話回線などで通信している場合は、数時間掛ることを覚悟した│ │ 方がいいでしょう。また、途中で回線が切れてしまった場合は、ディレ│ │ クトリを消して1からやり直すことをお勧めします。 cvs はこの様な異│ │ 常状態に対してあまり robust ではありません。 │ │ │ │ │ │ ここまで手順通りに行ってきた場合、 /usr/local/src/samba/samba-ja という │ │ ディレクトリが作成され、その下に samba の最新のソースコードが展開されて │ │ います。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ PentiumIII + Linux の場合30Mbyte │ │ │ └──────────────────────────────────────┘ ┌────────────────────────────────────────────────────┐ │[ 管理番号: 000000000026 ] │ │ Q. 取りあえずソースコードから普通にビルドするには? │ │ CVS でソースコードを獲得しました。 binary package がない OS です。どうやって Samba をインストールす │ │ ればいいのでしょう? │ │ │ │A. 次のステップにしたがってください。 │ │ 取りあえず [管理番号: 000000000025] に合わせて、 /usr/local/src/samba/samba-ja に CVS で獲得したソー│ │ スツリーが存在するとします。 │ │ ━━━━━━━━━━━━━━━━━━━━━━━━ │ │ │ │ まず /usr/local/src/samba/samba-ja/source に移動します。 │ │ % cd /usr/local/src/samba/samba-ja/source │ │ │ │ │ │ 次に configure スクリプトを実行して、あなたの環境に適合した Makefile を作ります。というか作れないか │ │ どうか、調べます。でも、その前にまずこれを実行してみてください。 │ │ % ./configure --help │ │ │ │ │ │ configure は必ず「./configure」と指定してください。もし、何らかの理由で「configure」とするだけで / │ │ usr/local/src/samba/samba-ja/source/configure が実行できてしまう場合は、 [管理番号: 000000000027] を│ │ 参照してください。 │ │ │ │ この configure の結果はバージョンによって異なりますが、例えば次のような結果になるはずです。 │ │ Usage: configure [options] [host] │ │ Options: [defaults in brackets after descriptions] │ │ Configuration: │ │ --cache-file=FILE cache test results in FILE │ │ --help print this message │ │ --no-create do not create output files │ │ --quiet, --silent do not print `checking...' messages │ │ --version print the version of autoconf that created configure │ │ Directory and file names: │ │ --prefix=PREFIX install architecture-independent files in PREFIX │ │ [/usr/local/samba] │ │ --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX │ │ [same as prefix] │ │ --bindir=DIR user executables in DIR [EPREFIX/bin] │ │ --sbindir=DIR system admin executables in DIR [EPREFIX/sbin] │ │ --libexecdir=DIR program executables in DIR [EPREFIX/libexec] │ │ --datadir=DIR read-only architecture-independent data in DIR │ │ [PREFIX/share] │ │ --sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc] │ │ --sharedstatedir=DIR modifiable architecture-independent data in DIR │ │ [PREFIX/com] │ │ --localstatedir=DIR modifiable single-machine data in DIR [PREFIX/var] │ │ --libdir=DIR object code libraries in DIR [EPREFIX/lib] │ │ --includedir=DIR C header files in DIR [PREFIX/include] │ │ --oldincludedir=DIR C header files for non-gcc in DIR [/usr/include] │ │ --infodir=DIR info documentation in DIR [PREFIX/info] │ │ --mandir=DIR man documentation in DIR [PREFIX/man] │ │ --srcdir=DIR find the sources in DIR [configure dir or ..] │ │ --program-prefix=PREFIX prepend PREFIX to installed program names │ │ --program-suffix=SUFFIX append SUFFIX to installed program names │ │ --program-transform-name=PROGRAM │ │ run sed PROGRAM on installed program names │ │ Host type: │ │ --build=BUILD configure for building on BUILD [BUILD=HOST] │ │ --host=HOST configure for HOST [guessed] │ │ --target=TARGET configure for TARGET [TARGET=HOST] │ │ Features and packages: │ │ --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) │ │ --enable-FEATURE[=ARG] include FEATURE [ARG=yes] │ │ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] │ │ --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) │ │ --x-includes=DIR X include files are in DIR │ │ --x-libraries=DIR X library files are in DIR │ │ --enable and --with options recognized: │ │ --enable-maintainer-mode enable some make rules for maintainers │ │ --with-smbwrapper Include SMB wrapper support │ │ --without-smbwrapper Don't include SMB wrapper support (default) │ │ --with-afs Include AFS support │ │ --without-afs Don't include AFS support (default) │ │ --with-dfs Include DFS support │ │ --without-dfs Don't include DFS support (default) │ │ --with-krb4=base-dir Include Kerberos IV support │ │ --without-krb4 Don't include Kerberos IV support (default) │ │ --with-krb5=base-dir Include Kerberos 5 support │ │ --without-krb5 Don't include Kerberos 5 support (default) │ │ --with-automount Include AUTOMOUNT support │ │ --without-automount Don't include AUTOMOUNT support (default) │ │ --with-smbmount Include SMBMOUNT (Linux only) support │ │ --without-smbmount Don't include SMBMOUNT support (default) │ │ --with-pam Include PAM password database support │ │ --without-pam Don't include PAM password database support (default) │ │ --with-ldap Include LDAP support │ │ --without-ldap Don't include LDAP support (default) │ │ --with-nisplus Include NISPLUS password database support │ │ --without-nisplus Don't include NISPLUS password database support (default) │ │ --with-nisplus-home Include NISPLUS_HOME support │ │ --without-nisplus-home Don't include NISPLUS_HOME support (default) │ │ --with-ssl Include SSL support │ │ --without-ssl Don't include SSL support (default) │ │ --with-sslinc=DIR Where the SSL includes are (defaults to /usr/local/ssl) │ │ --with-syslog Include experimental SYSLOG support │ │ --without-syslog Don't include SYSLOG support (default) │ │ --with-profile Include profile support │ │ --without-profile Don't include profile support (default) │ │ --with-netatalk Include experimental Netatalk support │ │ --without-netatalk Don't include experimental Netatalk support (default) │ │ --with-quotas Include experimental disk-quota support │ │ --without-quotas Don't include experimental disk-quota support (default) │ │ --with-utmp Include experimental utmp accounting │ │ --without-utmp Don't include experimental utmp accounting (default) │ │ --with-privatedir=DIR Where to put smbpasswd (/usr/local/samba/private) │ │ --with-lockdir=DIR Where to put lock files (/usr/local/samba/var/locks) │ │ --with-swatdir=DIR Where to put SWAT files (/usr/local/samba/swat) │ │ --with-sambabook=DIR Where to put Using Samba book (/usr/local/samba/swat/using_samba) (default) │ │ --without-sambabook Don't install Using Samba book │ │ --with-i18n-swat Use i18n'ed SWAT │ │ --without-i18n-swat Don't use i18n'ed SWAT (default) │ │ --with-swat-def-lang=LANG default SWAT language for old web browsers (empty) │ │ --disable-nls do not use Native Language Support │ │ │ │ │ │ ここで最も重要なのは │ │ --enable and --with options recognized: │ │ 行以降の設定です。自分にとって重要な設定はどれなのか、よーーーーく考えて、configure につけるオプショ│ │ ンを決定してください。なお、英語が判らない、という苦情は受け付けません (^^;) この程度も理解できない │ │ なら、Samba を導入してはいけません。 │ │ │ │ configure のオプションが決まったら、 root になり、その通りにスクリプトを実行します。 │ │ % su root │ │ │ │ │ │ Samba の configure スクリプトには、 root でないと正しくテストできない内容が含まれています。 [脚注 1]│ │ │ │ configure を実行した結果、エラーが発生しなかったことを確認してください。もしエラーが発生した場合、そ│ │ の内容を注意深く確認してください。 │ │ │ │ エラーの内容によっては、単に configure に追加するオプションを変更するだけで回避できるものもあるでし │ │ ょう。あるいは Samba の機能を制限しなくてはいけなくなるかもしれませんが、それはそれで諦めるか、何ら │ │ かの方法でそのオプションが使えるようにするしかないでしょう。 │ │ │ │ エラーの内容によっては、何をどうしても回避できない場合もあり得ます。この場合、OS やマシンを変えるし │ │ かない可能性があります。諦めてください。 │ │ │ │ configure の実行に成功したとしましょう。次に実行するべきは make です。まだ root 権限のままのはずです│ │ 。このままビルドしましょう。 │ │ │ │ │ │ make の段階で失敗する可能性が、まだあります。 │ │ │ │ コンパイラーが適切ではないかも知れません。 ANSI-C 対応ではないコンパイラーの場合、 Samba のコードを │ │ コンパイルできないかもしれません。 │ │ │ │ ライブラリがあまりにも古すぎて、あるいはシステムコールの引数が違っていて、コンパイルが通らないかも知│ │ れません。 │ │ │ │ configure での適合性テストが不完全なのかもしれない。 │ │ │ │ まぁ、可能性はいっぱいありますが、問題が発見されたら１つづつ対処して下さい、としか言えません。 │ │ │ │ 最近の OS であれば問題が発生することは滅多にないはずですが、最近の OS であれば大抵の場合、 binary │ │ kit を作る方法もあるので、この場合、成否は結構微妙だったりします…。 │ │ │ │ 取りあえず、make にも成功したとしましょう。最後に行うべきは install です。 │ │ │ │ │ │ /usr/local/samba というディレクトリが作られ、この下に /usr/local/samba/bin, /usr/local/samba/var, / │ │ usr/local/samba/lib, /usr/local/samba/private などのディレクトリが作成されます。 │ │ │ │ /usr/local/samba/bin の下には実行ファイルが、 /usr/local/samba/lib の下には smb.conf などのファイル │ │ が、 /usr/local/samba/var の下には log ファイルが、 /usr/local/samba/private の下には smbpasswd のよ│ │ うなセキュリティーファイルがそれぞれ格納されています。あるいは格納することになります。 │ │ ━━━━━━━━━━━━━━━━━━━━━━━━ │ │ │ │ Samba のバイナリをインストールする作業そのものはこれで終りですが、このままでは Samba を daemon とし │ │ て自動起動する所までは、いっていません。 │ │ │ │ しかし、ここでいきなり Samba daemon を起動しようとしないでください。その前に smb.conf を設定し、手で│ │ smbd/nmbd を起動して設定が正しいことを確認してください。これが確認できない状態で Samba を自動起動で │ │ きるようにしてはいけません。 │ │ ━━━━━━━━━━━━━━━━━━━━━━━━ │ │ │ │[脚注 1] │ │ これ自体が Security 上危険である可能性はあります。 │ │ │ └────────────────────────────────────────────────────┘ smb.conf の設定 smb.conf 設定に関する Tips 並びに、 smb.conf 設定までに考慮すべき事 ┌──────────────────────────────────────┐ │[ 管理番号: 000000000002 ] │ │ Q. coding system の推奨値 │ │ coding system はどの様な値にすると良いのでしょうか? │ │ │ │A. │ │ まず、どの coding system を選んでも、 Windows 側からはほぼ同じように見え│ │ ます。従って、これを決める要因は Unix 側の環境に依存することになります。│ │ 絶対的なルールはありませんが、一般的な規則は次の通りです。 │ │ │ │ EUC, EUC3 │ │ EUC で書き込みます。 │ │ Samba をインストールする Unix システムが EUC で日本語に対応したファ │ │ イルシステムを持っている場合使うと便利。大抵の場合この様なシステムで│ │ は ls などは EUC 対応である。 Unix の大抵のファイルシステムは EUC を│ │ 利用してファイル名を作成しても問題を生じることはないので、個人利用に│ │ お勧めです。 │ │ ただし、Shift JIS との完全な互換性がないため、一部の機種依存文字など│ │ が表現できない可能性があります。 │ │ SJIS │ │ Shift JIS で書き込みます。 │ │ Unix 側で Shift JIS を使いたい場合、指定します。例えば Unix システム│ │ が Shift JIS をサポートしている場合、あるいは Unix システムが FAT フ│ │ ォーマットの floppy disk をサポートしていて、さらにそこへの Shift │ │ JIS 書き込みをサポートしている場合、利用すると便利です。 │ │ 今の所、 Samba は Windows Client とは Shift JIS でファイル名のやり取│ │ りをしているので、 EUC などと異なり使えない文字なども生じません。 │ │ ただし、Unix システムが Shift JIS に対応していて、さらに ls などのコ│ │ マンドも Shift JIS に対応していることは稀です。そのため Unix 上でフ │ │ ァイルを操作する場合、最も苦労する危険性があります。逆に、これがサポ│ │ ートされている場合は、最も快適な環境になるでしょう。 │ │ CAP │ │ Macintosh 用のファイルサーバーソフトである CAP と互換性のある方法で │ │ ファイル名を書き込みます。 Unix 上でのファイル名は ASCII 文字列に展 │ │ 開された形になります。 │ │ CAP や Netatalk と連携する場合は、CAP を選ぶ必要があります。 │ │ ただし、ファイル名が長くなる性質を持っているので、ファイルシステムの│ │ 制限ギリギリの長さのファイル名の場合、 SJIS や EUC では書き込めるよ │ │ うな長さのファイル名でも、書き込めなくなる場合があります。 │ │ HEX │ │ 文字コードを ASCII コードに変換する独自の方式でファイル名を書き込み │ │ ます。おおざっぱに言うと、ファイル名はおおよそ 3倍のバイト数を必要と│ │ することになりますが、この制約の範囲では、最も Unix システムに対する│ │ 制約が少ない方式です。 │ │ ただし、Unix 上でファイル名を調べようと ls などを実行しても、そのま │ │ までは全く判らない、という欠点があります。 │ │ UTF8 │ │ UTF-8 でファイル名を書き込みます。 │ │ ファイルシステムが UTF-8 でのファイル名記述を保証している場合、最も │ │ ストレスなく利用できるようになるでしょう。 │ │ 最大の弱点は、このようなシステムがまだない (少なくとも筆者は知らな │ │ い) という点だろう。 │ │ │ │ ただし、企業などのインフラとして Samba を利用する場合は、次のように考え │ │ た方が良い、という意見が私自身にはあります。 │ │ │ │ UTF-8, SJIS, EUC は使うな │ │ 企業インフラの一環であるネットワークファイルシステムとして Samba を │ │ 利用する場合、 Samba Server 上のデータは基本的に Samba Server の寿命│ │ よりも長い、と考えるべきです。この場合、現在利用している Server OS │ │ を将来も使い続ける保証はありません。また、現在使っている OS の後継 │ │ OS がサポートする文字コードが変わってしまう可能性もあります。 │ │ 何らかのシステムクラッシュによって過去に取った backup image からシス│ │ テムを復旧する必要もでるかもしれませので、この問題は移行の際にだけ気│ │ をつければ良い問題ではありません。文字コードが OS にサポートされてい│ │ ない場合、 backup image が読めない、それも問題のファイル名以降がすべ│ │ て読めなくなる、などの問題につながる恐れがあるからです。 │ │ Samba が前提としている OS である Unix やそのクローンの場合、 OS の変│ │ 化に強い影響を受けない文字コードは ASCII だけです。従って、CAP ある │ │ いは HEX だけを用いるべきでしょう。 │ │ Macintosh との連携が不要ならば CAP を使うな │ │ CAP は CAP 並びに Netatalk に合わせたエンコーディングを行います。こ │ │ れはつまり、このエンコーディングは基本的に MacOS に合わせてある、と │ │ いう事を意味します。 │ │ Shift JIS には、過去のしがらみから、機種依存文字問題という問題があり│ │ 、 NEC PC-98xx シリーズと IBM-PC、そして Macintosh の3種類はそれぞれ│ │ 異なる文字コードに機種依存文字を持っています。このため、CAP では一部│ │ の機種依存文字に対応できない、あるいは対応しても Macintosh 側で読み │ │ 込めない、という問題が発生します。 │ │ Macintosh との連携を必要とする場合は、 CAP を使い Macintosh/Windows │ │ の双方で機種依存文字を使わない、という方策以外手はありません。が、も│ │ し、Macintosh との連携を必要としないならば、 HEX を使うのが最も簡単 │ │ にこの問題から逃げる方法です。 │ │ │ │ この条件に従うならば、 HEX が推奨値と言うことになります。ただし、HEX を │ │ 利用する場合、 Unix 上でのファイル操作は最も煩雑になりますので、覚悟は必│ │ 要です。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000017 ] │ │ Q. deadtime って何? │ │ man smb.conf とやると deadtime という値がありました。これは何ですか? │ │ │ │A. 0 か 1 に設定するべき変数 │ │ 百分は一見にしかず。実験をしてみましょう。 │ │ │ │ まず、イタズラをしても良い Samba server と Windows Client を 1台づつ用意│ │ します。以下の説明では ./configure で普通にビルドした場合のディレクトリ │ │ 構成で説明しますので、自分の環境に合わせて適宜読み替えてくださいね。 │ │ │ │ まず、/usr/local/samba/var の下にある log ファイルを全て消します。 │ │ │ │ smbd, nmbd をそれぞれ適切に起動してください。この段階で /usr/local/samba│ │ /var のしたには smb.log, nmb.log の2つのファイルがあるはずです。 │ │ │ │ Windows マシンで、この Samba の公開しているディレクトリをドライブにマウ │ │ ントしてみてください。 /usr/local/samba/var には .log というフ│ │ ァイルが新しくでき、 │ │ $ ps -ef | grep mbd │ │ │ │ の結果も新しく smbd が1つ増えているはずです。 │ │ │ │ さて、ここで、 smbd, nmbd を完全に殺してください。基本的には親 smbd, │ │ nmbd に kill -TERM で済むはずです。 Windows マシンは特にエラーを出してい│ │ ませんよね? │ │ │ │ で、再度 smbd, nmbd を起動してみてください。特に Windows からのコネクシ │ │ ョンが発生していないことは │ │ $ ps -ef | grep mbd │ │ │ │ の結果から判るはずです。 │ │ │ │ ここで、Windows からマウントしたドライブを開いてみてください。一度 │ │ Server とのコネクションが切れていたにも関わらず、何もなかったかのように │ │ 平然とコネクションが復活することが判るはずです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 実は、SMB によるコネクションは、ファイルが1つもロックされていない場合、 │ │ コネクションが切れても問題は発生しません。分かりやすく言えば、ファイルも│ │ ディレクトリも開いてなければ Server が落ちても平気なんです。なくなったコ│ │ ネクションは Client が必要になったときにそれを復帰しようとして、失敗した│ │ ら始めてエラーになります。逆に言えば、復帰しようとしたときまでに Server │ │ が再起動していれば、 Windows からは何も問題がなかったように見える、と言 │ │ う事。 │ │ │ │ deadtime という変数は、この「コネクションを切る」という動作を意図的に起 │ │ すための変数です。 │ │ │ │ deadtime は 0 あるいは自然数を受け付けます。 0 の場合、Samba はコネクシ │ │ ョンを切ろうとはしません。 │ │ │ │ 自然数(つまり1以上の整数)の場合、指定した minute だけコネクションが発生 │ │ しなかった場合、 Samba はコネクションを切断し、 smbd は終了します。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ smbd と Client がコネクションを維持する場合、相互確認のため、つまり互い │ │ にシステムがダウンしていないことを確認し合うために、おおよそ 20秒に一度 │ │ の割合で keepalive という ack を投げ合います。このパケットは、ネットワー│ │ クが混雑している場合、ネットワークにとっても擾乱要因となりますし、サーバ│ │ ーにとっては(結局これも IP packet ですので) 演算負荷となります。 │ │ │ │ また、smbd が沢山動いていると言う状態は、それだけで kernel のスケジュー │ │ ルを必要とするプロセスが増大するという事ですし、有効な TCP port が増えて│ │ いるためにそれらの面倒を見るためにも、 CPU 負荷、memory 負荷が共に増える│ │ ことを意味します。高負荷時にこれは Server にとって辛い状況です。 │ │ │ │ この様な場合には、事実上使われていないコネクションは落しておいた方が良い│ │ わけです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ コネクションを維持しなかった場合の問題点は、コネクションの復元にかかるオ│ │ ーバーへッドです。たとえば deadtime を 1分に設定したのはいいが、 61秒ご │ │ とにファイルを書き込みに来られたら、コネクションを切り、smbd を終了し、 │ │ その直後にコネクションを復元するために smbd を分身し直すためにかかるオー│ │ バーへッドがただの負担としてかかってしまいます。この負荷は deadtime が 0│ │ の場合は発生しません。しかし、普通はアプリケーションは起動時と終了時、あ│ │ と十数分に一度の割合でファイルを書き換えるのが一般的です。 │ │ │ │ また、コネクションが切れてしまうと、復元にかかる時間分、アプリケーション│ │ などの動作がもたもたした感じをうけます。これがユーザビリティーに影響を与│ │ える可能性もあります。これはアプリケーションの動作に強く依存するので、実│ │ 際に使ってみないと判りません。 │ │ │ │ ただ、コネクションはどうせ切るのであるならば、可及的速やかにコネクション│ │ を切った方が有利です。従って、deadtime は 0 にしないならば、 1 にするの │ │ が最も良いことになります。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ deadtime を 1 に設定しても、役に立たない場合もあります。ファイルやディレ│ │ クトリが開かれたままのアプリケーションを使う場合です。もっとも極端な例が│ │ Explorer です。 Explorer はフォルダの中身を参照していると、アイコンを参 │ │ 照するため、等の理由でファイルやディレクトリをバカバカと開きまくります。│ │ 問題は参照後ちゃんと閉じていないことがある、という点です。 │ │ │ │ 従って、この場合は、Explorer をなるべく使わないようにするなどの対策が必 │ │ 要になります。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ もし、Server 負荷が低いのであれば、あるいはネットワーク負荷が低いのであ │ │ れば、無理をして deadtime を 1 にする必要はありません。コネクションを切 │ │ らなくても負担でないならば、コネクションを切らない方がユーザビリティーは│ │ 向上します。 │ │ │ │ │ └──────────────────────────────────────┘ その他 Samba 運営上の問題 Samba を運営する上での、その他の問題 ┌──────────────────────────────────────┐ │[ 管理番号: 000000000019 ] │ │ Q. ディレクトリに対するシンボリックリンクの削除 │ │ ディレクトリに対するシンボリックリンクを消そうとすると、リンク先のディレ│ │ クトリにあるファイルまで一緒に消えてしまいます。どうにかなりませんか？ │ │ │ │A. なりません。それはそんなことをしたあなたが悪いのです │ │ まず、この問題がなぜ発生するのかから考えましょう。 │ │ │ │ Windows の大抵のツールは、ディレクトリ削除を実行する際に、まずディレクト│ │ リの下にある全てのファイル(とディレクトリ)の削除を実行します。で、ディレ│ │ クトリが空になってから、ディレクトリそのものを削除します。 │ │ │ │ ディレクトリがシンボリックリンクの場合、シンボリックリンク出さされた先の│ │ ディレクトリを、 Client からの命令に従って削除します。その後、ディレクト│ │ リを削除しろ、という命令が飛んでくるのですが、ここで始めて対象がシンボリ│ │ ックリンクであることを確認し、シンボリックリンクの削除を実行します。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ ここまでの段階だけを見ると、Samba が悪いように見えます。 │ │ │ │ Windows がシンボリックリンクを知らないから悪いのであって、それをちゃんと│ │ 対処しない Samba が悪い、と考えられるからです。 │ │ │ │ この考えは適切ではありません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ まずは unix のディレクトリに対するリンクの特徴から見ていきましょう。 │ │ │ │ ディレクトリに対するリンクにはハードリンクとシンボリックリンクの両方があ│ │ ります。 POSIX 準拠の場合、ディレクトリに対するハードリンクは root だけ │ │ が実行できるのですが、それでもハードリンクとシンボリックリンクの両方が可│ │ 能です。 │ │ │ │ この「ディレクトリに対するリンク」という発想は、実は unix が最初に採用し│ │ たファイルシステム Interface の弱点が色濃く継承されています。 │ │ │ │ そもそも、古典的なファイルシステムには、ディレクトリを作成するための API│ │ は存在しませんでした。 mknod で directory 属性付きの inode と block イメ│ │ ージとしてのディレクトリを作成し、 link 命令で '.' と '..' エントリを追 │ │ 加する、というのがディレクトリの作り方だったのです。 │ │ │ │ この作り方をする限り、 1つのディレクトリに対して複数のリンクを張ることを│ │ 防止する方法はありません。 │ │ │ │ しかし一方で、当時は unix はカーネルのソースコードを読んで使うもの、とい│ │ うユーザーしかいなかったので、この構造だからと言って不用意にディレクトリ│ │ の中のファイルを全て消してしまう、というようなトラブルを起すような利用者│ │ はいませんでした。 │ │ │ │ 問題はむしろ、 mknod と link という2つのコマンドが必要だったため、ディレ│ │ クトリ作成に atomicity がない、という点にありました。 2つ以上のプログラ │ │ ムが同時にディレクトリを作成しようとしている場合、ディレクトリイメージま│ │ では作成できるのに link ができない、という状態が発生してしまうのが問題だ│ │ ったのです。 │ │ │ │ この問題を解決するために、 SVR3 で mkdir と rmdir システムコールが作られ│ │ 、これを期にディレクトリを mknod で作製する方法は禁止されました。当然、 │ │ これに伴い unlink でディレクトリを削除するべきではない、ともされました。│ │ ディレクトリは rmdir で削除するべきだと。 │ │ │ │ しかし、ディレクトリに対するリンクは、特にハードディスクの容量が少なかっ│ │ た昔は、便利なものでした。 unix はそもそもが制御ファイルがテキストファイ│ │ ルで肥大化し易く、さらにソースコードが必ず存在していた、という事実がこれ│ │ に追い討ちをかけました。 include ファイルの多くはカーネルのソースコード │ │ のファイルと一致しており、このためカーネルのディレクトリを丸々コピーする│ │ よりもディレクトリを丸ごとリンクしてファイルを共有した方が便利だったので│ │ す。 │ │ │ │ そして、この様なディレクトリ共有は、ディレクトリそのものが read only な │ │ 場合は全く問題を起しません。 │ │ │ │ このため、ディレクトリに対するリンク機構は存続することになりました。その│ │ 後、root だけに許されるように制限が強化されましたが、それでもディレクト │ │ リに対するリンクを張ることは可能なままです。 │ │ │ │ 当然、unlink も可能ですが、不適切な操作により、ディレクトリ並びにその下 │ │ にファイルが存在する状態のままディレクトリに対する reference counter が │ │ 0 になってしまった場合、基本的に、ファイルシステムは破綻を来たします。こ│ │ の場合、破綻を解消するかどうか、また「どう解消するのか」は、全てシステム│ │ 依存になっています。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 一方で、シンボリックリンクはハードリンクよりもさらに問題がやっかいです。│ │ │ │ シンボリックリンクは基本的に、「つけ替え」作業しか行いません。あるシンボ│ │ ル名は別の「シンボル名」に対する alias に過ぎません。シンボル名が何を指 │ │ しているのか、あるいはそこに実体があるのかどうか、は一切問題になりません│ │ 。 │ │ │ │ 当然、シンボリックリンクが指している先が、ファイルになったり、ディレクト│ │ リになったりと、その時々に応じて変化しても問題とはなりません。 │ │ │ │ シンボリックリンクは、それがシンボリックリンクであることを検出する方法を│ │ 提供し、それに対してどうアプローチするのか、という点を完全にアプリケーシ│ │ ョンに委ねてしまっています。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ ここまでを要約すると、こうなります。 │ │ │ │ unix においては、ディレクトリに対するリンクは、ハードリンクであれソフト │ │ リンクであれ、利用者が適切に利用することを前提とし、システム(OS やファイ│ │ ルシステム)のレベルではなんらの危機防御機構を持ち合わせていないのです。 │ │ │ │ 従って、ディレクトリに対するリンクは、全て「利用者側の責任に置いて」作成│ │ され、利用されなくてはいけません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 実はこの事実、Application プログラムが │ │ 必ず責任を取るようにコーディングできるわけではない │ │ │ │ と言う重要な事実をも指摘しています。 │ │ │ │ そもそも、ここで必ず責任を取るようにコーディングできるのならば、 OS レベ│ │ ルでもそのように実装することも可能です。そのように実装することはできない│ │ 、でも機能を切ることもできない、だからユーザー側に責任を押し付けているの│ │ です。 │ │ │ │ そもそも、「１つの実体を２つの名前が指す」という状態の、『意味』を考えて│ │ みましょう。実は、答は少なくとも2つ、存在することが判ります。 │ │ │ │ 1つ目は、2つの名前がおなじ実体を指しているのは、あくまでも一つの実体を2 │ │ つの名前で参照したいから、という場合です。この場合、どちらの名前で参照し│ │ ている場合でも、変更(削除は変更の一種)は一度に効果を持たなくてはいけませ│ │ ん。どちらかの名前で実体を削除する場合は、その実体を指している全ての「リ│ │ ンク」を削除するのが正しい有り様になります。 │ │ │ │ 2つ目は、2つの名前は実は異なる実体を指したいのだが、同じ内容であることが│ │ 判っているので、同じ内容の間は同じものを指し示そう、というものです。これ│ │ は copy on modify モデルと言って、昨今の unix ではプロセスを fork で増や│ │ す場合、メモリ空間に対してこのモデルが使われます。この場合、どちらかの名│ │ 前で何らかの変更を要求した場合、まず変更側がコピーされ、それに対する変更│ │ が施されます。 │ │ │ │ この2つのどちらの意味で実装するのであっても、「1つの実体を2つの名前が参 │ │ 照している」状態は正しい状態を意味します。しかし、逆に言えばアプリケーシ│ │ ョンはこの2つのどちらの意味なのかを決定しなくてはいけません。あるいは、 │ │ 両方を実装してユーザーに決定させる必要があります。 │ │ │ │ 特に1つ目の場合はやっかいで、「1つの実体を消去する」事と、「実体へのリン│ │ クを消去する」事は全く異なることになります。 unix には unlink() システム│ │ コールしかありませんから、この作業は atomicity を欠いています。あるファ │ │ イルに対して「実体を削除するべく」全てのハードリンクを消そうとしているア│ │ プリケーションと、そのファイルに対するレプリカを作るべくどんどんリンクを│ │ 作成し続けるアプリケーションが同時に動いたら、これはレース状態になってし│ │ まうでしょう。下手をすれば、永久に止まりません。 │ │ │ │ ましてや、あるアプリケーション、あるユーザーが、どちらの意味でディレクト│ │ リ構造に対するリンクを実装したとしても、別のユーザー、別のアプリケーショ│ │ ンが、もう一方の意味で実装することを止めることはできませんし、 2つのアプ│ │ リケーションが異なる意味でディレクトリに対するリンクを使い出したら、当然│ │ 矛盾が発生します。 │ │ │ │ 具体例を上げてみましょう。 vi と emacs という、unix 上の 2 大エディター │ │ は、今の所シンボリックリンクはちゃんとトレースして、実体を変更するように│ │ なっていますが、ハードリンクに対しては vi は実体に対する変更を、 emacs │ │ は copy on modify を意味します。このように異なるアプリケーションは、異な│ │ る結果をもたらすのです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ unix のディレクトリに対するリンク機構は、最初から、このように利用者の理 │ │ 解を要求します。逆に言えば、これらの事実を理解せずにディレクトリに対して│ │ リンクを張っても、望み通りの結果が得られず被害を被るだけであり、その状態│ │ が「当然」なのです。 │ │ │ │ 従って、任意のユーザーに公開するディレクトリに対して何らかの形で多重リン│ │ クを張るべきではありません。 │ │ │ │ 唯一の例外は、ディレクトリ並びにその中身が全て read only の場合です。こ │ │ の場合、変更・削除が生じる可能性はなくなり、結果として矛盾が発生する可能│ │ 性は0になります。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 以上が unix のディレクトリに対するリンクの特徴です。 │ │ │ │ 一方 Windows の方はと言うと、これは比較的簡単です。 1つの実体に対して2つ│ │ の名前を割り振る方法はありません。 │ │ │ │ いや、これは厳密には正しい表現ではありませんでした。 MS-DOS 2.11 の頃、 │ │ MS-DOS にはディレクトリエントリーのファイル開始 FAT 番号を任意の番号にす│ │ り替えるインターフェースがありました。これを利用すればディレクトリであろ│ │ うがファイルであろうが、任意のものに対する多重リンクに相当する構造を作る│ │ ことは可能でした。 │ │ │ │ ただしこの場合は、この多重リンク対象のファイルやディレクトリを変更・削除│ │ することは許されません。他のインターフェースは多重リンクの存在を知らない│ │ ままファイルシステムを操作するので、 FAT 管理情報などが全て矛盾してしま │ │ うからです。 │ │ │ │ 多重リンクを作れても、それが read only ではあまり実用性はありません。単 │ │ にファイルシステムが混乱する元が増えるだけです。おそらくはそのためでしょ│ │ う。 MS-DOS 3 以降、このインターフェースは削除され、今もこれに相当するイ│ │ ンターフェースは用意されていません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ Windows には「ショートカット」という特別なファイルがあるかのように見える│ │ かも知れませんが、ショートカットは特別なファイルではありません。ショート│ │ カットは Explorer が特別扱いする .lnk 拡張子を持ったファイルで、その中身│ │ は Explorer がそのファイルをクリックした場合に実行するべき内容が記述され│ │ ているだけの、通常ファイルです。 │ │ │ │ これが「通常ファイル」である最大の意味は、「Windows という OS はこのファ│ │ イルを特別扱いしない」という事です。普通のアプリケーションから見て、この│ │ ファイルは普通のファイルでしかなく、別にそこに書かれているリンクを手繰っ│ │ てくれるわけでも何でもありません。 │ │ │ │ 実際、ショートカットの中に書かれているのは、『そのファイルをクリックされ│ │ たらどの様に挙動するべきか』という挙動です。これは一種のバッチファイルで│ │ あり、 unix でいうシンボリックリンクなどとは全く意味が違います。 │ │ │ │ 従って、ショートカットファイルをシンボリックリンクの代わりに利用したり、│ │ Samba 側でシンボリックリンクをショートカットにマップしたりするのは、全く│ │ のナンセンスです。ましてや、ハードリンクに対する対策を考慮していない、と│ │ いう点からも、このような発想は論外でしかありません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 結局の所、Samba は unix のディレクトリ管理システムに従うしかありません。│ │ 一方で、Samba は Client からのリクエストを1つづつ忠実に実行することしか │ │ できません。 │ │ │ │ Client が掌握できない概念は Samba でも提供することはできませんから、ある│ │ ものが多重リンクである、と言う事実を Windows に伝えることはできませんし │ │ 、その一方で Windows が「消せ」と言ってきたファイルやディレクトリは、そ │ │ の実体が何であれ、消そうとする以外手はないのです。 │ │ │ │ 従って、 │ │ Samba に公開するディレクトリを多重リンクで作成してはいけない │ │ │ │ という事実をキチンと守らなくてはいけない、このルールに従うのは unix 側で│ │ リンクを張る人の義務である、と言う事になります。 │ │ │ │ この要求は決して理不尽なものではありません。 │ │ │ │ Windows 側から Samba を経由して、ハードリンクであれ、シンボリックリンク │ │ であれ、多重リンクを作ることはできません。従って、Samba 経由で参照できる│ │ ディレクトリ上に多重リンクが存在する場合、その作者は unix 上でこの多重リ│ │ ンクを作成したことになります。ということはこの作者は unix ファイルシステ│ │ ムの弱点を承知でリンクを張った、と言う事であり、その結果当然、守るべきル│ │ ールを守っている、事が要求されるからです。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000020 ] │ │ Q. シンボリックリンク2 │ │ じゃぁディレクトリに対するシンボリックリンクは作るべきではないんですね? │ │ │ │A. │ │ まず、「シンボリックリンク」を特別視するのをやめるべきです。 │ │ │ │ そもそもが、この問題は unix のファイルシステムが抱える多重リンクに対する│ │ インターフェースの不備と不完全さに原因があります。多重リンク状態を作成す│ │ ることはできるが、セマンティカル(意味論的)に一意的な意味が与えられていな│ │ いのが、根本的な問題点なのですから。 │ │ │ │ 一意な意味が与えられていないインターフェースを、そのような概念を知らない│ │ OS が叩けば、埃が出ても当然です。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ これらの意味が破綻しなくなる場合はたった1通りしかありません。リンク先の │ │ 実体が read-only で作られている場合です。 │ │ │ │ ここでいう「リンク先の実体」とは、ファイルの場合は単にファイルの実体だけ│ │ ですが、ディレクトリの場合はそのディレクトリ下にある全てのディレクトリと│ │ ファイルを指します。 │ │ │ │ なぜ read-only なら問題がないのかというと、多重リンク構造を作った段階で │ │ 矛盾がないならば、それを変更、削除できなければ矛盾は生じないからです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 実際にはこれでは困る場合もあります。ディレクトリ上のファイルのいくつかは│ │ 変更したい、という要望は当然あり得るからです。 │ │ │ │ この場合は、「ディレクトリ」を多重リンクするのではなく、ディレクトリ構造│ │ 自体はコピーし、ファイルに対してだけリンクを張る、という手があります。 │ │ │ │ X11 の膨大なソースコードと、それに対する変更研究は、 │ │ 『オリジナルコードの read-only 状態での確実な保存』 │ │ という要求と、 │ │ 『自分が興味感心があるファイルに対する自由な変更』 │ │ という矛盾した要求を生み、結果 lndir というツールが作られるに至りました │ │ 。このツールはオリジナルディレクトリを再帰的に検索し、ディレクトリツリー│ │ は完全に再現した上で、ファイルだけはオリジナルに対するシンボリックリンク│ │ を作成します。 │ │ │ │ こうやってできた「レプリカディレクトリ」上の任意のファイルに対し、ファイ│ │ ルのコピーを作成し、オリジナルを削除してから、コピーをオリジナルの名前に│ │ rename する、という作業を施すと、そのファイルだけがレプリカディレクトリ │ │ 上オリジナルのファイルになります。このファイルをいくら変更してもオリジナ│ │ ルのツリーに影響を与えることはありません。 │ │ │ │ この場合、copy on modify モデルが実装できたことになります。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ Samba で、copy on modify モデルでファイルを提供する場合も同様です。 │ │ │ │ オリジナルのファイルを read-only 属性にした上で適当なディレクトリに置き │ │ 、それに対するレプリカディレクトリを作成してこれを公開します。 │ │ │ │ ディレクトリを削除しようとした場合は、シンボリックリンクとレプリカディレ│ │ クトリが削除されるだけなのでオリジナルファイルに対して影響を与えることは│ │ ありません。 │ │ │ │ ディレクトリ上のファイルを変更しようとした場合は、ファイルをコピーし、 │ │ rename することを教えれば、あるいは、Windows 上のエディターは大半がその │ │ ように動くので何もせずにそのまま放置しておいても、シンボリックリンクは削│ │ 除され、新しくその場に作られたファイルは「そのディレクトリオリジナルの」│ │ ファイルになります。 │ │ │ │ 1つ注意すべきなのは、このモデルの場合、オリジナルのファイルが存在するデ │ │ ィレクトリを、ここで提供しているモデルの実体を理解していない人には、絶対│ │ 見せてはいけない、と言う事です。この「実体」を削除されてしまったら、全て│ │ のシンボリックリンクが無効になってしまうからです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ Samba で、copy on modify モデルでレプリカディレクトリを提供する場合、フ │ │ ァイルへのリンクをハードリンクにしてはいけません。 │ │ │ │ ハードリンクはオリジナルファイルのデータを全く防御なく直接アクセスさせま│ │ す。 chmod などのシステムコールは確実に実体の access permission を変更し│ │ てしまいます。すると、Modify (オリジナルのファイルを開いて、そのまま │ │ write 命令でデータを一部上書きすること) 作業をオリジナルファイルに実行で│ │ きるようになってしまいます。 │ │ │ │ これでは copy on modify としては動作しません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 一方、『単一実体』モデルを実装することは、 Samba 上では不可能です。先ほ │ │ どのハードリンクの例はまさに「単一実体」の挙動そのものに聞こえるのですが│ │ (そして、確かにこれに関してはその通りなのですが)、別の挙動に問題があるの│ │ です。 │ │ │ │ unix は『単一実体』モデルを実装できていません。このため、ファイルの削除 │ │ の段階で「ハードリンクを1つ削除する」ことはできても、「ハードリンクを全 │ │ て削除して実体を消去させる」事はできません。 │ │ │ │ Windows Client には「多重リンク」の概念はないので、 Windows Client は多 │ │ 重リンクを意識したコマンドを発行しません。 Windows Application にとって │ │ は、あるファイルを開いて write コマンドで変更するのと、別のファイルをつ │ │ くって必要なイメージを作った後で、ファイル名を rename するのは等価、ある│ │ いは critical section が短くなる分後者の方が優れていると見なすでしょう。│ │ │ │ このような世界では、rename の瞬間にハードリンクを全て張り直してオリジナ │ │ ルの状態に復元する必要がありますが、 rename の少し前には古いファイルを消│ │ 去しなくてはいけません。ということは rename が実行されたときにはリンク情│ │ 報は完全に消失している、と言う事ですから復元は不可能です。 │ │ │ │ 少し前の状態を覚えておけば…という方法は実用的ではありません。別のアプリ│ │ ケーションが「旧来通りの復元を不可能にする」ファイルを作ったら復元は不可│ │ 能であり、この場合「可能な限り復元する」事でさえ適切ではありません。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 基本的に Samba で公開しているディレクトリやファイルに多重リンクを使うの │ │ はやめるべきです。どうしてもという場合は、read-only なファイルに対しての│ │ み、行いましょう。 │ │ │ │ │ └──────────────────────────────────────┘ Samba と直接関係しないその他の話 Samba と直接関係はしないが、知っておくと Samba を管理・運営等する上で役に立つ話 。 ┌──────────────────────────────────────┐ │[ 管理番号: 000000000001 ] │ │ Q. man, HTML, TeX ファイルをテキストにするには? │ │ man や HTML, TeX ファイルから plain text を作るにはどうすれば良いでしょ │ │ うか? │ │ │ │A. │ │ man の結果を plain text に変換するには col を使うのが簡単です。 man ls │ │ の結果を plain text に変換する場合は │ │ man ls | col -b > ls.txt │ │ │ │ とします。 │ │ │ │ man そのものの結果ではなく、 man フォーマットで記述されているファイルを │ │ plain text に変換する場合は、 │ │ cat ls.1 | /usr/bin/troff -msafer -man -Tascii | grotty -b -u │ │ │ │ で変換できます。 │ │ │ │ 一方 HTML を plain text に変換するには、 lynx や w3m( ) のような HTML brouser の機能│ │ を使うのが簡便です。 │ │ lynx -dump sample.html > sample.txt │ │ │ │ w3m -dump sample.html > sample.txt │ │ │ │ │ │ TeX ファイル、正確には TeX や LaTeX, AMS-TeX などの TeX の仲間のファイル│ │ は、一旦 dvi ファイルに変換する必要があります。変換方法は TeX ファイルが│ │ 正確には何なのかに依存するので割愛します。 │ │ │ │ dvi ファイルに変換したら、あとは から得た dvi2tty を用いて │ │ dvi2tty sample.dvi > sample.txt │ │ │ │ で plain text に変換できます。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000014 ] │ │ Q. PC や Server の時刻を一致させるには? │ │ PC と Samba Server の時刻が一致していないため、ファイルをコピーすると未 │ │ 来から来たファイルができたり、ファイルの作成時刻が逆転したりします。どう│ │ すればいいのでしょう? │ │ │ │A. Network Time Protocol 対応ソフトを使おう │ │ インターネット経由の時刻合わせには、 NTP を使うと良いでしょう。 │ │ │ │ とりあえず、ちょっと雑誌等を調べただけで、 │ │ │ │ 高エネルギー物理学研究所 gps.kek.jp(130.87.42.34) │ │ 東北大学 ntp1.tohoku.ac.jp(130.34.11.117) │ │ 東北大学 ntp2.tohoku.ac.jp(130.34.48.32) │ │ 東京大学 eric.nc.u-tokyo.ac.jp(130.69.251.23) │ │ 東京理科大学 sutntp.sut.ac.jp(133.31.180.6) │ │ 広島大学 ns.hiroshima-u.ac.jp(133.41.4.2) │ │ 福岡大学 clock.nc.fukuoka-u.ac.jp(133.100.9.2) │ │ 豊橋技術科学大学 ntp.tut.ac.jp(133.15.64.8) │ │ │ │ などの NTP サーバーが発見できます。 │ │ │ │ これらを直接使っても良いですし、これらとは別のソースから時刻を取ってきて│ │ も良いのですが、とりあえず何らかの形でまず正しい時刻をどこかのサーバーマ│ │ シンに設定します。で、このマシンをローカルな NTP Server として利用します│ │ 。 │ │ │ │ その上で、桜時計 や TClock < │ │ URL: http://homepage1.nifty.com/kazubon/ > などを使って Windows マシンの│ │ 時刻を合わせます。 │ │ │ │ ローカルな NTP Server に unix を使う場合は、 ntp を使うと良いでしょう。一方ローカルな時刻サー │ │ バーに Windows を使う場合は、上記の桜時計を使う、と言うのが手です。 │ │ │ │ FreeBSD などいくつかの OS では、 OS 標準で NTP Server/Client の xntpd/ │ │ ntpdate が組み込まれています。これを利用すると簡単で良いでしょう。 │ │ │ │ ちなみに SNTP は NTP の時刻合わせ機能を単純化したものだそうです。 │ │ │ │ │ └──────────────────────────────────────┘ ┌───────────────────────────────────────────┐ │[ 管理番号: 000000000015 ] │ │ Q. TCP 再送状況を獲得するには? │ │ smb.conf の最適化の所にはやたらと TCP の再送状況を調べろとありますが、具体的にどう│ │ やればいいんですか? │ │ │ │A. netstat -s を使え │ │ netstat -s -p tcp │ │ │ │ │ │ 命令を使うのが一般的です。ただし、もし netstat が -s を FreeBSD や Linux と同じ意 │ │ 味で使っているならば、ですが。 │ │ │ │ TCP は流量制御のために、ターンアラウンドタイムや、転送総量、再送量などを port ごと│ │ に全て管理しています。ですので、再送状況に関する情報も kernel の中のどこかに必ずあ│ │ ります。 │ │ │ │ FreeBSD や Linux の場合は、 netstat コマンドを -s オプションつきで実行すると、 │ │ netstat の出力状況ががらりと変わってこれらの情報が獲得できるようになります。 │ │ │ │ netstat の出力は次のような感じになります。これは VineLinux 2.1 の場合の、私のマシ │ │ ンに関しての出力です。 │ │ │ │ $ netstat -s │ │ Ip: │ │ 350 total packets received │ │ 0 forwarded │ │ 0 incoming packets discarded │ │ 348 incoming packets delivered │ │ 263 requests sent out │ │ Icmp: │ │ 0 ICMP messages received │ │ 0 input ICMP message failed. │ │ ICMP input histogram: │ │ 0 ICMP messages sent │ │ 0 ICMP messages failed │ │ ICMP output histogram: │ │ Tcp: │ │ 6 active connections openings │ │ 0 passive connection openings │ │ 0 failed connection attempts │ │ 0 connection resets received │ │ 4 connections established │ │ 251 segments received │ │ 251 segments send out │ │ 0 segments retransmited │ │ 0 bad segments received. │ │ 2 resets sent │ │ Udp: │ │ 12 packets received │ │ 0 packets to unknown port received. │ │ 0 packet receive errors │ │ 12 packets sent │ │ │ │ $ netstat │ │ Active Internet connections (w/o servers) │ │ Proto Recv-Q Send-Q Local Address Foreign Address State │ │ tcp 0 0 localhost.localdo:32774 localhost.localdom:wnn6 ESTABLISHED │ │ tcp 0 0 localhost.localdo:32770 localhost.localdom:5680 ESTABLISHED │ │ tcp 0 0 localhost.localdom:wnn6 localhost.localdo:32774 ESTABLISHED │ │ tcp 0 0 localhost.localdom:5680 localhost.localdo:32770 ESTABLISHED │ │ Active UNIX domain sockets (w/o servers) │ │ Proto RefCnt Flags Type State I-Node Path │ │ unix 13 [ ] DGRAM 1179 /dev/log │ │ unix 3 [ ] STREAM CONNECTED 9922 /tmp/.X11-unix/X0 │ │ unix 5 [ ] STREAM CONNECTED 9921 │ │ unix 3 [ ] STREAM CONNECTED 8569 /tmp/.esd/socket │ │ unix 3 [ ] STREAM CONNECTED 8568 │ │ (中略) │ │ unix 2 [ ] DGRAM 3960 │ │ unix 2 [ ] DGRAM 2859 │ │ unix 2 [ ] DGRAM 2856 │ │ unix 3 [ ] STREAM CONNECTED 2645 │ │ unix 3 [ ] STREAM CONNECTED 2644 │ │ (後略) │ │ │ │ $ netstat -g │ │ IPv6/IPv4 Group Memberships │ │ Interface RefCnt Group │ │ --------------- ------ --------------------- │ │ lo 1 224.0.0.1 │ │ eth0 1 224.0.0.1 │ │ │ │ $ netstat -i │ │ Kernel Interface table │ │ Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg │ │ eth0 1500 0 92 0 0 0 0 0 0 0 BRU │ │ lo 16192 0 363 0 0 0 363 0 0 0 LRU │ │ │ │ $ netstat -r │ │ Kernel IP routing table │ │ Destination Gateway Genmask Flags MSS Window irtt Iface │ │ 10.0.0.0 * 255.255.255.0 U 40 0 0 eth0 │ │ 127.0.0.0 * 255.0.0.0 U 40 0 0 lo │ │ │ │ │ │ なお、少なくとも Vine-Linux 2.1 についてくる netstat(8) のマニュアルには -s オプシ│ │ ョンに関する説明がありません。どうも、net-tools 1.54, netstat 1.38(1999-04-20)に関│ │ しては man netstat との間に齟齬があるようです。マニュアル自体の日付としては一致し │ │ ているので、おそらくこれはパッケージ自体の齟齬でしょう。 │ │ netstat --help │ │ │ │ │ │ のようにして、直接 netstat の help を見た方が良いでしょう。 │ │ │ │ 追記情報 │ │ Windows 98, 98SE, NT, 2000 にも netstat.exe という同様のことをしてくれるプログ│ │ ラムが標準で存在します。 C:\Windows あるいは C:\WinNT の下を探してください。 │ │ │ │ │ └───────────────────────────────────────────┘ ┌───────────────────────────────────────┐ │[ 管理番号: 000000000016 ] │ │ Q. Samba の新版などを簡便に入手するには? │ │ 目的とするファイルの URL がはっきり判っているときに、 Netscape や ftp を使│ │ わずに目的のファイルを獲得するにはどうすればいいでしょうか? │ │ │ │A. wget があります。 │ │ FreeBSD の場合は fetch というプログラムが標準でついてきますが、 Linux など│ │ の場合はこれに相当するプログラムとしては、 の wget があります。このプログラムはほぼ全てのデ│ │ ィストリビューションで入手可能です。 GNU ソフトウェアですので、おそらく大 │ │ 抵の unix 環境で実行可能でしょう。 │ │ │ │ 例えば、本 QandA の最新版を獲得する場合は、 │ │ % wget http://fjskyousosama.holy.jp/Documents/Samba-QandA.euc.txt │ │ % wget http://fjskyousosama.holy.jp/Documents/Samba-QandA.j.html │ │ │ │ │ │ のように実行することで、テキスト版や html 版をカレントディレクトリに持って│ │ くることができます。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ 巨大なファイルを獲得する場合、 ftp を使っても相応に時間がかかります。 │ │ │ │ この場合、 ftp を使うと欲しいファイルを獲得した後もコネクションが維持され │ │ てしまい、ファイルサーバーになってくれているマシンに負荷となってしまいます│ │ 。だからといって、ダウンロードに4時間もかかる場合にずっとマシンの前に座っ │ │ ている、と言うのも苦痛です。 │ │ │ │ wget は指定された URL からファイルを獲得すると自動的にコネクションを切って│ │ くれます。このため、wget に欲しいファイルの URL を列挙して与えておき、自分│ │ は離席する (例えば、家のマシンにダウンロードを指定しておいて、自分は会社に│ │ 出社するとか) などを行うことができます。 │ │ │ │ FreeBSD では、 ports において必要なファイルがない場合は fetch を使って必要│ │ な URL からファイルを持ってくることができるようになっています。 wget を使 │ │ えば、これと同じような構造を作り上げることができるでしょう。 │ │ │ │ │ └───────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000018 ] │ │ Q. トラフィック・データを収集するには? │ │ ネットワークの状況を監視するのが重要なのは判るのですが、どうやればいい │ │ の? │ │ │ │A. MRTG を使うらしい │ │ にある The Multi│ │ Router Traffic Grapher というツールを使うと、トラフィックデータを収集、 │ │ 視覚化できるそうです。 │ │ │ │ Simple Network Management Protocol(SNMP) を用いて、同一セグメントに接続 │ │ されたルータやサーバの負荷状況を報告させる仕組みだそうだ。負荷状況はグラ│ │ フ化され、さらに HTML でブラウズできるようにしてくれるそうだ。 │ │ │ │ perl と C で記述されたフィルター群で、補助ライブラリも結構使うらしいが、│ │ 便利そうだ。 │ │ │ │ すべて推定なのは、私自身は使っていないから。これは全て日経Linux 2001-3月│ │ 号のうけうり。 │ │ │ │ │ └──────────────────────────────────────┘ ┌──────────────────────────────────────┐ │[ 管理番号: 000000000027 ] │ │ Q. PATH 環境変数に . を追加してはいけないわけは? │ │ カレントディレクトリにあるプログラムを ./ をつけずに実行できるようにする│ │ ために、 PATH 環境変数に . を追加しています。そしたら │ │ 「やめろ!馬鹿もの!Crack されたいのか!!」 │ │ と一喝されました。そんなに悪いことなんでしょうか? │ │ │ │A. 極悪非道です │ │ まず、その一喝してくれた方を今後は「師匠」と呼ぶことをお勧めします。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ Cracker があなたのマシンを攻撃する場合、 root だけでなく、一般ユーザーの│ │ 誰かとしてのアクセス権限が獲得できないかトライします。仮に、 Cracker が │ │ この攻撃に成功したとしましょう。 Cracker は当然、次に root になれないか │ │ 画策することでしょう。この場合、Cracker が取る手段の一つに次のようなもの│ │ があります。 │ │ │ │ まず、Cracker はあなたが root のときに、 PATH にカレントディレクトリを含│ │ めている可能性を考慮します。そして、root に限らず、大抵のユーザーが使う │ │ であろうコマンド、並びにその打ち間違いのバリエーションを考えて、それらの│ │ コマンドを実行しようとした場合に、可能ならばシステムのデフォルトプログラ│ │ ムよりも前に Cracker の作ったプログラムが実行される可能性に「賭ける」の │ │ です。 │ │ │ │ もちろん、そのようなファイルがどこにでも作れるわけではありませんが、 │ │ unix の場合、/tmp というディレクトリには誰でもファイルが作れるので、ここ│ │ に、ls (や、その打ち間違い sl ), dir などのコマンドファイルを実行権限付 │ │ きで置いておきます。 │ │ │ │ root は、案外 /tmp の状態を調べる必要があるので、 /tmp において ls コマ │ │ ンドを実行することはかなりの確率で、あります。 │ │ │ │ たとえば PATH の先頭に . が登録してあると、 /bin/ls ではなく /tmp/ls が │ │ 実行される可能性があります。また、PATH の最後に . が登録してあると /bin/│ │ ls が実行される確率は高いのですが、打ち間違いがある場合 /tmp/sl が実行さ│ │ れる可能性は非常に高くなります。 │ │ │ │ Cracker が置いた実行ファイルを実行した場合、そのプログラムが次の手順を取│ │ ると、 Cracker は root の権限を得ることができるようになります。 │ │ │ │ 1. Cracker が設置した /tmp/ls や /tmp/sl などのファイルを削除し、自分の│ │ 足跡を消す │ │ 2. 分身する。親プロセスは今度は /bin/ls を実行して、なにもなかったかの │ │ ように実行を続け、終了する。 │ │ 3. 子プロセスは、Cracker との通信を確保して、 Cracker から与えられたコ │ │ マンドの通りに行動する。 │ │ │ │ この場合、子プロセスは root 権限を持ち、なおかつ Cracker の言う通りに挙 │ │ 動するので、Cracker が利用するための新たなユーザーの登録、 kernel に対す│ │ るパッチ(これは、単に kernel レベルで Cracker の言う通りに挙動するだけで│ │ なく、自分以外の者が侵入できないようにするための防壁の強化も含まれる) の│ │ 適用など、好き勝手ができるようになります。 │ │ │ │ こうなってしまうと、もはやそのマシンは reboot しても Cracker の言いなり │ │ になってしまいます。 │ │ │ │ この様な状態を回避するには、カレントディレクトリのような状況に応じて変わ│ │ ってしまうディレクトリや、 /tmp のような誰でも書き込みができるディレクト│ │ リを PATH から外す必要があります。確実に安全なツールだけを使って、カレン│ │ トディレクトリに対する安全を確認し、意識的に指定しない限り、カレントディ│ │ レクトリ上のプログラムを実行できないようにする必要があります。 │ │ │ │ なお、BSD 4.3 の頃はデフォルトで PATH の先頭に . が含まれていました。こ │ │ の頃は Cracker などという「不埒な」連中のことを考えなくて済むぐらい、平 │ │ 和だったのです。 │ │ ━━━━━━━━━━━━━━━━━ │ │ │ │ これで判ったでしょう。こんな危険な状態では「いちいちのんびりと理由を説明│ │ している間にも」攻略されてしまう可能性があります。このような危険な状態に│ │ 対して兎に角叱責してくれる人は、まさに「師匠」そのものなのですよ。 │ │ │ │ 叱られたくなかったらまず、それだけの主張をするにふさわしい実力をつけまし│ │ ょう。 │ │ │ │ │ └──────────────────────────────────────┘