Table of Contents
cupsomatic/foomatic
の役割mime.convs
cupsaddsmb
用のsmb.conf
の準備*.tdb
ファイルcupsaddsmb
が、新しくインストールしたプリンターで動かない/var/spool/samba/
のアクセス許可が、再起動後毎回リセットされるList of Figures
List of Tables
ldap passwd sync
の値pam_smbpass
で認識されるオプション
List of Examples
smb.conf
に記述する複数LDAPサーバーsmb.conf
smb.conf
smb.conf
エントリの設定この本の表紙には「オフィシャルSamba-3 HOWTOとリファレンスガイド」 初版の「自由(freedom)」のテーマを踏襲している。先駆者人たちの行動の源泉 を問いかけることで過去を振り返ってもよいだろう。過去から何も得られないとい うことはまずあり得ない。我々の前に人生を歩んだ彼らの業に思いを馳せるか どうかに関わらず、我々の自由を護った彼らに対する誇りと感謝の念を忘れる ことがあってはならない。
情報テクノロジーの進化は、恐怖を抱かせるペースで進んでいる。時代の要求に 応えるかに見える進化を受け入れてきたのが人間の本性であるが、これは将来 の我々を罠にかけることにもなりかねない。情報テクノロジーの短い歴史の中 にすら、多くの実例がある。かつて MS-DOS は、我々を大型コンピュータのシ ステムを運用するコストから解放し、今日我々が享受している急速な発展を可 能としたツールと見なされていた。しかし、今日我々は、時代遅れで忘れたい 時代に束縛する技術として、侮蔑の念を以て MS-DOS を振り返っている。
Windows ネットワーク、Windows NT 4.0、近年の Active Directory と続く発 展は、今でこそ時代の先端を進んでいるように見えかも知れないが、遅かれ早 かれ、より優れたものに取って替わられる運命にある。拡張された認証情報ソ リューションやディレクトリに対する近年の注目は、想定外の事態ではない。 これらの技術が脚光を浴びる一方で、現在活気があり、力強いように見えてい たものが夜の冷たい風(the chilly wind of the night)のように扱われる日が きっとくる。何が待ち受けていようとも、進歩に逆らうことは考えられない。
Samba の開発は着々と行われている。Samba 3.0.0 からの変貌は驚くべきもの であるが、より高度でかつ迅速な進化が多くの人々から求められている。 近年の開発の成果はすぐに目に見える形で表れているが、それでもパンドラの 箱を開けるのにドキュメントが必要である。ネットワーク管理者が最小の手間 で新しい機能を迅速に導入する上で、本書がなんらかの助けになれば幸いであ る。導入を推進し、新しく実現する機能により得られたメリット(直訳:マイ レージが稼げる)を通じて、前途に待ち受けている世界に思いを馳せてほしい。 とりわけ、Samba がもたらした選択の自由を味わい、シームレスな相互接続性 がもたらす可能性を楽しんでほしい。
Andrew Tridgellmailto:tridge@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Karl Auermailto:kauer@biplane.com.au
Dan Shearermailto:dan@samba.org
John H. Terpstramailto:jht@samba.org
Andrew Tridgellmailto:tridge@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
David Bannonmailto:dbannon@samba.org
Guenther Deschnermailto:gd@suse.de (LDAP updates)
John H. Terpstramailto:jht@samba.org
Volker Lendeckemailto:Volker.Lendecke@SerNet.DE
Guenther Deschnermailto:gd@suse.de (LDAP updates)
John H. Terpstramailto:jht@samba.org
Jeremy Allisonmailto:jra@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
Andrew Tridgellmailto:tridge@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
Guenther Deschnermailto:gd@suse.de (LDAP updates)
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
Jonathan Johnsonmailto:jon@sutinen.com
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
Jeremy Allisonmailto:jra@samba.org
Guenther Deschnermailto:gd@suse.de (LDAP updates)
Olivier (lem) Lemairemailto:olem@IDEALX.org
グループのマッピング: Microsoft Windows と UNIX
John H. Terpstramailto:jht@samba.org
Jean François Micouleau
Gerald (Jerry) Cartermailto:jerry@samba.org
John H. Terpstramailto:jht@samba.org
Volker Lendeckemailto:Volker.Lendecke@SerNet.DE
Guenther Deschnermailto:gd@suse.de
John H. Terpstramailto:jht@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Jeremy Allisonmailto:jra@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org (drawing)
Jeremy Allisonmailto:jra@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Eric Rosememailto:eric.roseme@hp.com
Andrew Tridgellmailto:tridge@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Rafal Szczesniakmailto:mimir@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org (drawing)
Stephen Langasekmailto:vorlon@netexpress.net
Microsoft 分散ファイルシステムツリーのホスティング
Shirish Kalelemailto:samba@samba.org
John H. Terpstramailto:jht@samba.org
Kurt Pfeiflemailto:kpfeifle@danka.de
Gerald (Jerry) Cartermailto:jerry@samba.org
John H. Terpstramailto:jht@samba.org
Kurt Pfeiflemailto:kpfeifle@danka.de
Ciprian Vizitiumailto:CVizitiu@gbif.org (drawings)
Jelmer R. Vernooijmailto:jelmer@samba.org (drawings)
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Tim Pottermailto:tpot@samba.org
Simo Sorce (original vfs_skel README)
Alexander Bokovoy (original vfs_netatalk docs)
Stefan Metzmacher (Update for multiple modules)
Ed Riddle (original shadow_copy docs)
Tim Pottermailto:tpot@linuxcare.com.au
Andrew Tridgellmailto:tridge@samba.org
Naag Mummanenimailto:getnag@rediffmail.com (Notes for Solaris)
John Trostelmailto:jtrostel@snapserver.com
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Stephen Langasekmailto:vorlon@netexpress.net
Microsoft Windows ネットワークへのSambaの統合
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
たかはし もとのぶmailto:monyo@home.monyo.com (日本語サポート)
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Jeremy Allisonmailto:jra@samba.org
Jeremy Allisonmailto:jra@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
John H. Terpstramailto:jht@samba.org
John H. Terpstramailto:jht@samba.org
Andrew Tridgellmailto:tridge@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
Dan Shearermailto:dan@samba.org
Gerald (Jerry) Cartermailto:jerry@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
David Bannonmailto:dbannon@samba.org
Dan Shearermailto:dan@samba.org
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
Andrew Tridgellmailto:tridge@samba.org
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Andrew Tridgellmailto:tridge@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Dan Shearermailto:dan@samba.org
Jim McDonoughmailto:jmcd@us.ibm.com (OS/2)
Paul Cochranemailto:paulc@dth.scot.nhs.uk
Jelmer R. Vernooijmailto:jelmer@samba.org
John H. Terpstramailto:jht@samba.org
Gavin Henrymailto:ghenry@suretecsystems.com
John H. Terpstramailto:jht@samba.org
Johnが彼の最新の本のために、最初に私に紹介の文を書いてくれと依頼してきたとき、 彼が私を選んだことについて幾分不可解に思った。Johnと会話して、真の理由はわか り、彼は記事の残りを埋めるために、私にそれを任せた。そのため、背景について少 しばかり我慢するのをいとわないのであれば、Johnが提供しないであろう 記事の部分を提供しよう。
私はSun Microsystemsの企業標準ディレクタで、Sunの技術標準を管理している。それ 以前は、Johnに出会った、Netscapeでの技術標準ディレクタであった。Sun以前には、 DECでやはり標準についての仕事をしていた。私はいくつかの、標準についての本を書 き、分野としての標準を推進する、技術とビジネストレンドについての観察(時々助言) の傾向がある。技術的な分野としてではなく、管理ツールとして標準化を見る傾向が あるが、これはJohnが話してくれた理由の一部である。
あなたが以前に持っている、何らかの方法で特定の標準化手法に注目した本は、それゆ え標準についての本である。標準について留意することのうち最も重要なものは、作成 の手順の正当性である。標準は、ビジネスでも、技術的な理由のためでもなく、より深 くてずっとやむにやまれない理由のために作成される。標準は、人々が意味のある方法 で通信が出来るようにするために作成されて使われる。あらゆる標準は、それが真の標 準ならば、人々の間で関連するコミュニケーションを増大させるという完全な(そして 唯一の)ゴールセットを持つ。
しかしながら、標準が文書化されない限り、この主要なゴールには到達できない。それ が誰でも知っているようにそれらのドキュメントを提供する顕著 な感情だった時、私は余りに多くの標準化の効果の改善を行っていた。彼ら が言って、知っている現在の それらは良い規格を破滅させるものである。彼らが知っているのなら、 なぜ標準化をしようとするのか?
人々が使い方を知っているので、よい標準は存続する。それが見 えなくなるくらいに簡単で、わかりやすくて、明快な時にどのように標準を使うかを知 る。うまく使う方法を記述している文書がはっきりしていで、明確で正しいときだけ、 標準は見えなくなる。これらの3つの要素は役に立つ標準のために存在しなければならな く、明白な取り組みなしで生じる、2つの分離しで異なったエンティティの間で、コミュ ニケーションと相互作用を許す。この本を読んだ後、3つの特徴の形跡を探すことと、 どのようにそれらがJohnの文書中に隙間無く織り込まれているかを注意しなさい。 正当性のない明快性と一意性は技術的な悪夢を提供する。曖昧さ がある、正当性と明快性は、おそらく小さな問題を発生させるが、明快性のない正当性 と一意性はシナリオを通して混乱状態を起こす。
そして、これが、Johnが彼自身はっきり言うことが出来ない(か望まない) 残りの話である。人-機械、機械-機械、人-人にせよ、2つあるいはそれ以上 のエンティティの間でのコミュニケーションのための資格と、コミュニケーションを増 大させるための標準を使いたいと思う誰かにとってユーザーの役に立つように、Sambaの、 明確で簡潔で、一意性があり、技術的に有効な表現である。この本の意図は、誰に対し ても、政治的、技術的、社会的な議題を納得させないことにある。意図は、Sambaについ て知りたい、どのように使うか、主要な責任を得る方法について知る必要があるユーザー に対しての文書を提供することである。Sambaの文書が素晴らしく成功して、Johnの部分 に誇りがある間、特定な仕事を達成するためのツールを必要とし、Sambaをそのツールと することを選んだ誰かのために文書を書く。
この本は、Johnの、Sambaに対する忍耐と献身と、私に言わせるならば、標準化のゴール である記念碑である。この本を書くことによって、Johnは、物事をより明確に、簡単に、 最終的に価値ある資源にするために配布することを望むSambaのユーザーに提供した。さら に、彼は非常に役に立つ、標準に対する理解と、ユーティリティを増加させ、そして、 これに関して、文書と同じくらい、我々の人生をより扱いやすくさせる標準に頼る我々 から感謝されている。
Carl Cargill, Senior Director |
Corporate Standardization, The Office of the CTO |
Sun Microsystems |
Table of Contents
編集者は、この本を買ってくれたことに対して感謝する(訳注:最初に本として出版されていたため)。公式のSamba-3 HOWTOと リファレンスガイドは情報、フィードバック、TIPS、ヒントと幸福なソリューション の長年の蓄積の結果である。
この本は、内容が常に更新されている、生きている文書であることに注意。よりSambaユー ザにとって貴重な、この本の次の版を作るのを手助けするために、TIPS、テクニック、 役に立つヒント、Windowsネットワーク領域に関する特別な洞察を寄贈する事を勧める。
以前に行われたものよりも、より広範囲な、よりうまくSambaを使えるためとネットワー クユーザーにより多くの満足度を与えるかもしれない情報を協力して文書化した。
この本は、設定の例を提供し、それは、Microsoft Windowsネットワークの要点を文書化 し、Samba-3の重要な設定に対する徹底的な洞察を提供し、それらのすべてを役に立つフ レームワーク中に置くのを支援する。
この文書の、一番新しい電子的な版は、 http://www.samba.org/ 上の“ドキュメント” ページで参照できる。
更新、パッチと修正は最も希望されるものである。以下の誰かに情報をメールで送ってほしい:
Jelmer Vernooij (jelmer@samba.org) |
John H. Terpstra (jht@samba.org) |
Gerald (Jerry) Carter (jerry@samba.org) |
オリジナルと間違いがなくなったものが公開されることを助言することを願う。 著作権者からの同意のないものを公開しないでほしい。
以下の表記方法がこの本を通じて使用される:
TOSHARG2 は、“公式Samba-3 HOWTOとリファレンスガイド第二版” 編集者: John H. Terpstra and Jelmer R. Vernooij, Publisher: Prentice Hall, ISBN: 0131882228 の省略形として使われる。
S3bE2 は、 “Samba-3 by Example第二版” 編集者: John H. Terpstra, Publisher: Prentice Hall, ISBN: 013188221X の 略として使われる。
ディレクトリとファイル名はmonoフォントである。たとえば、
/etc/pam.conf
となる。
実行ファイル名は太字となる。たとえば smbd
である。
メニュー項目とボタンは太字となるたとえば、
をクリック である。選択メニューは以下のように表示される:
→ → →Table of Contents
“ 人の贈り物はその人のために道を 開き、高貴な人の前にも彼を導く(訳注:聖書 18:16節?)。 Gifts are like hooks that can catch hold of the mind taking it beyond the reach of forces that otherwise might constrain it. ” --- Anon.
この本はSambaについての本である。多くの人の善意と、努力と、たくさんの作業から出 来上がったツールである。この本には、我々の後に続く人と同じように、価値をお互い に分け与える絶え間ない信条で寄贈されてきたものを含む。
この本は、Microsoftネットワーク管理者の必要に適合するために企画された。必要として いると考えている情報を見つけにくいと不満があるかもしれないが、UNIX管理者もこの本 から得るところがある。そのため、もしもあなたがMicrosoft認定のスペシャリストならば、 この本はあなたの要求をかなり満たすはずである。もしもUNIXかLinux管理者ならば、 現在の関心事に対する回答を探すのに苦労がないということにひどいと 感じる必要性もない。
Sambaは巨大で複雑なプロジェクトである。Sambaプロジェクトは野心的でわくわく するものである。Sambaを支えているチームは世界中に分散した30余人からなり、 興味深い範囲のバックグラウンドから来ている。このチームには科学者、エンジ ニア、プログラマ、ビジネスマンと学生がいる。
チームのメンバーは、Microsoft Windowsと非Microsoft IT技術領域の間での、 ワクワクする相互運用性に到達するのを助けるという願望ことを通じて、 積極的に参加していた。
Sambaプロジェクトの背景にある、努力を結集するためのスローガンは: Samba, Opening Windows to a Wider World!である。 プロジェクトの背景にあるゴールは、相互運用性の障害をなくすことである。
SambaはMicrosoft Windows クライアントのための、ファイルと印刷サービスを 提供する。それらのサービスは、任意のTCP/IPベースのプラットフォーム上で 提供されてよい。オリジナルの開発プラットフォームはUNIXとLinuxだが、現在 は、多くのシステム上で広く使われている。
Sambaプロジェクトは特徴的なファイルと印刷サービスの機能を含むだけではなく、 クライアントの機能や、Sambaへの簡単なマイグレーション用ユーティリティ、 Microsoft Windowsとの相互運用性支援ツールと管理ツールを含むように拡張され ている。
Sambaを運用する人はあなたのような人である。 You have inspired the developers (the Samba Team) to do more than any of them imagined could or should be done. ユーザーのフィードバックはSambaの開発を推進する。Samba-3は、 ユーザーの要求、助言、とコードの寄贈の結果としての大量の仕事の結果 を特に含んでいる。
現在Sambaに関するたくさんの本が市場に出回っていて、それぞれ独自の 価値がある。一見過剰な量の本が出回っているが、十分な文書を提供しそこねる ことについてSambaプロジェクトはたくさんの苦情を受けている。Sambaはまた 設定することについてとても複雑で難しいことについても苦情を受けている。 もしもSambaが成功していなかったならば、苦情がないはずなので、これは たくさんの方法によるSambaの成功の証拠である。
Sambaチームのメンバーは主にUNIXとLinuxで仕事をしているので、Sambaの 文書がその位置づけを反映していることは驚くべきには値しない。オリジナルの HOWTOテキスト文書は、いくつかのTIPS、とても貴重な情報を提供するように 意図されていて、それが誰かの手助けになるならば、それはとてもすばらしい ことである。しかしHOWTO文書はきちんと構造化されて、文脈も不統一だった。 それは、渡すことで利便性を得られるかもしれない、だれかに渡すために書かれた 情報の独立した情報のスナップショットであった。それらは、便利にマニュアル ページ中に書かれるべき多くの情報を転送することの必要性を反映した。
オリジナルのHOWTO文書は異なった著者により書かれている。ほとんどのHOWTO 文書は多数の著者からの投稿とフィードバックの結果である。この本を読むと、 各章が複数の著者により、それぞれの著者はそれぞれのスタイルで書かれてい るのに気がつくだろう。このことはオープンソースソフトウェア開発プロセス の自然なスタイルを表している。
インターネット上に広まっている非公式なHOWTO文書の集まりは、オリジナルの HOWTO文書由来のものである。この作業はずっと継続して作られている価値ある 非公式のHOWTO文書を置き換えないようにしようとして いる。もしも、非公式のHOWTOを改良しているならば、その仕事を継続してほし い!
非公式のHOWTOの作成、Sambaに関する情報ページ、メーリングリストやその他 で問い合わせに答えることをボランティアでやっていた人はこれが愛の労働で あることを知っているかもしれない。あなたが集めた貴重な知恵を喜んで受け 取ることについて、あなたの貢献について知りたいので、 John H. Terpstra(jht@samba.org). まで投稿をメールで送ってほしい。他のユーザーに対するサービスとして、技術 的に正確なものを採用したい。
既存のSamba本はUNIX管理者向けである。既存の本が適切な目的に役に立つ、 Samba-3が今出ているという1つの例外を除くこのターゲットグループの 見通しから、アップデートの必要がある!
公式のSamba-3 HOWTOとリファレンスガイドというこの 本は、Sambaととともに提供されているSamba-HOWTO-Collection.pdfを含む。 これらの文書は新しいデザインと意図で書かれている。
過去2年にわたって、多くのMicrosoftネットワーク管理者たちはSambaを採用し てその展開に興味を持つようになった。彼らの情報に対する要求は、UNIX管理 者のものとはとても異なった。以前のMicrosoftネットワーク管理トレーニング と経験から、この本は調整されて、情報が表現されるようになった。
この本は6つの部分から出来ている:
Samba-3をすぐに走らせるための手助けとして用意されている。 Fast Startの章は、Microsoftネットワーク管理者からの、 すぐに動くいくつかのサンプル設定 を要求されたことへの直接的回答である。
この部分の目的は、既存のMicrosoft Windowsネットワークの知 識をSambaの技術や標準に変換するための方法である。この部 分の各章はそれぞれSambaサーバーの1つのインストールタイプ をカバーしている。
ネットワークブラウジングの仕組みはすべてのMicrosoft Windows ユーザーにとって鬼門であった。Samba-3では、新しいユーザーとマシン アカウント管理機能、新しい、UNIXグループとWindowsグループの マッピング方法、ドメイン間の信頼関係、新しい動的ロードファイル システムドライバー(VFS)やその他を導入している。この文書では、 デスクトップとユーザーポリシーのハンドリングについての情報と同様 の拡張された印刷に関する記述、拡張されたネットワーク統合のテク ニックが新しい。このセクションはこの本の中心となる所である。 しっかり読んでほしい。
Samba-2.xからSamba-3に移行するときの問題点の概観と同様、Windows NT4からSamba-3にどのようにMicrosoftグレーとするかについての情報が たくさんの要求によりこの本に追加された。
この短いセクションは試みがすべて失敗するときに手助けになる。
ここには、ほとんどのユーザーにとって末梢的なものとか、主要部分の 情報に含まれている残りのフィールドについての集積がある。
Microsoft Windowsと残りの世界との間での、相互運用性の新しい世界全体を楽しむあなたのユーザー を助けるための公開された最初の文書とSamba-3にようこそ。
Samba-HOWTOコレクションのこのセクションには、どのようにSambaをインストールするかと 多分必要と思われるSambaの一部分を設定する一般的な情報が含まれている。 まずこれを読んでほしい。
Table of Contents
Table of Contents
Sambaのバイナリパッケージは、ほとんどのLinuxかUNIXディストリビューション に含まれている。また、 the Samba home page(本家)にも いくつかのパッケージが置いてある。使用するOSに合わせたパッケージのイン ストールの詳細については、OSのマニュアルを参照してほしい。
もしもソースからSambaをコンパイルすることが必要ならば、 Sambaのコンパイル方法を参照してほしい。
Sambaの設定はsmb.conf
ファイルに格納され、それは、通常
/etc/samba/smb.conf
か
/usr/local/samba/lib/smb.conf
にある。このファイル
を自分自身で編集するか、あるいは、たとえば、Sambaに含まれているWebベー
スのインタフェースSWATのような、種々のGUIツールのどれかを使って編集する
ことができる。
smb.conf
ファイルは、昔のWindows 3.1で使われていたいろいろな
.ini
ファイルと同じ文法を使う。おのおののファイル
はいくつかのセクションからなり、それらは行の先頭が大括弧
([]
)で囲まれた、セクション名から開始される。それぞれ
は0またはそれ以上の、等号(=
)で分離されたキー/値ペア
を含む。ファイルは単なるテキストファイルなので、好みの編集ツールで開い
て編集できる。
smb.conf
ファイル中にあるおのおののセクションは、共有か、Sambaサーバー上
のメタサービスを記述している。[global]
セクションは特
別であり、Sambaサーバー全体にたいして適用する設定を含む。Sambaは複数の
メタサービスをサポートし、おのおのは固有の機能を提供する。例えば、
[homes]
共有は、メタサービスであり、おのおののユーザー
のための、個別のホーム共有を提供させる。[printers]
は
メタサービスであり、プリントキューサポートを確立し、それは、Windows
クライアントから、UNIX/Linuxプリントスプーラに対してプリントジョブが
送られることに先立ち、中間スプールディレクトリの位置を指定する。
printers
メタサービスは、printcap
ファイル中で指定されたものか、lpstat
コマンドか
CUPS API経由かでのすべてのプリンターを共有プリントキューとして公開する
ようにする。smb.conf
ファイル中のprinters
節は
browseable でないように設定できる。もしもbrowseableに設定すると、
共有として見えるようになる。これは、WindowsプリントキューとしてUNIX
システムプリンターを有効にするのみ反応するこのメタサービスをTmakes no
sense。もしも、comment
パラメーターが指定されるならば、
その値がWindowsエクスプローラーのブラウズリスト中にプリンター名の一部と
して表示される。
共有またはメタサービスを指定するsmb.conf
ファイル中のおのおののセクション
は節(stanza)と呼ばれる(訳注:日本ではセクションという呼び名が通用している
ため、以下はすべてセクションとする)。global
セクション
はsmb.conf
ファイル中のすべての他のセクションに影響する設定を指定する。
設定パラメーターはsmb.conf
マニュアルページに説明がある。いくつかのパラメーター
はglobal
セクションのみで使われ、その他いくつかは通常の
共有またはメタサービスセクションでのみ使われ、いくつかは、グローバルまたは
共有、メタサービスセクションで使える。
最小のsmb.conf はとても小さいsmb.conf
を含む。
この節では、Samba-3で使われるデータベースの簡単な説明を含む。
Sambaが格納するtdbファイルのディレクトリの位置は、コンパイル時オプ ションによって変わる。Samba-3は2つの場所にtdbファイルを格納する。 その位置を決める最も良い方法は、以下のコマンドを実行する:
root#
smbd -b | grep PRIVATE_DIR
PRIVATE_DIR: /etc/samba/private
これは、秘密のtdbファイルが/etc/samba/private
ディレクトリに格納されることを意味している。Samba-3はまた、より
ありふれたデータを含むいくつかのtdbファイルを使う。それらのファイルの
位置は以下を実行することで見つけられる:
root#
smbd -b | grep LOCKDIR
LOCKDIR: /var/lib/samba
それゆえ、例の中で表示されている残りの制御ファイルは
/var/lib/samba
ディレクトリに格納される。
継続的に使われるtdbファイルは
継続的なTDBファイルの説明一覧
にある。すべての継続的なtdbファイルは通常バックアップすべきである。
tdbファイルバックアップのためにtdbbackup
ユー
ティリティを使うこと。すべての継続的なtdbファイルはマシンの
マイグレーション、アップデートとアップグレードの間保存すべきである。
一時的なtdbファイルはバックアップの必要性はなく、マイグレーション、 アップデートとアップグレードの間保存する必要もない。一時的なtdb ファイルは 一時的なTDBファイルの説明 に説明がある。
Table 1.1. 継続的なTDBファイルの説明
名前 | 説明 |
---|---|
account_policy | Samba/NTアカウントポリシーの設定、パスワード満了の設定を含む。 |
group_mapping | Windows グループ/SID から UNIXグループへのマッピングテーブル。 |
ntdrivers | プリンター単位の、インストール済みドライバー情報を格納。 |
ntforms | プリンター単位の、インストール済みフォーム情報を格納。 |
ntprinters | プリンター単位の、devmode構成設定情報を格納。 |
passdb | tdbsamパスワードバックエンドが使われる時のみ存 在。このファイルはSambaSAMAccount情報を格納する。 注意:このファイルは/etc/passwdファイルからか他 の代替システムソースからのユーザーのPOSIXアカウント を必要とする。 |
registry | winreg RPC経由で種々のデータベーステーブルをエ クスポートすることをサポートするための、読み出 し専用Windowsレジストリスケルトンデータベース。 |
secrets | このファイルはWorkgroup/Domain/Machine SID、 LDAPディレクトリ更新パスワードとSambaが正常に 動作するために必要な重要な環境データのさらなる 集合。このファイルには、秘匿しなければならない とても機密性のある情報が含まれている。このファ イルはPRIVATE_DIRディレクトリに格納される。 |
share_info | 共有単位のACL情報を格納。 |
winbindd_idmap | Winbinddのローカル IDMAPデータベース。 |
Table 1.2. 一時的なTDBファイルの説明
名前 | 説明 | バックアップ |
---|---|---|
brlock | バイトレンジロック情報。 | No |
connections | 最大接続数を拡張するために使われる一時的な接続上のキャッシュ。 | no |
eventlog/*tdb | イベントログエントリのレコードほとんどの環境ではこれはシステムログのキャッシュである。 | no |
gencache | WINSサーバーと信頼されるドメインデータのための汎用キャッシュデータベース。 | no |
login_cache | ログイン情報のための一時的なキャッシュで、特に不正なパスワード試行用。 | no |
messages | smbdによって処理されるメッセージの一時的な格納用。 | no |
netsamlogon_cache | net_samloginリクエストからのユーザーnet_info_3 構造データのキャッシュ(ドメインメンバーとして)。 | no |
perfmon/*.tdb | パフォーマンスカウンタ情報。 | no |
printing/*.tdb | プリントサービス単位で作成されるlpqコマンドのキャッシュされた出力。 | no |
schannel_store | 機密ファイルで、PRIVATE_DIRに格納され、接続セッ トアッププロセスの再ネゴシエーションの必要なし で再接続可能な一時的な切断が可能になるための暗 号化した接続情報を含む。 | no |
sessionid | 種々のセッション情報とutmp処理のための一時的なキャッシュ。 | no |
unexpected | どのプロセスもリッスンしていない時に受け取ったパケットを格納する。 | no |
winbindd_cache | NT4ドメインかADSから受け取ったアイデンテティ 情報のキャッシュ。ユーザーリストなどを含む。 | yes |
Sambaは2つまたは3つのdaemonから構成される。daemonはバックグラウンドで動
作し、サービスを提供するUNIXのアプリケーションである。サービスの例としては、
httpd
と呼ばれるdaemonが Apache Webサーバーである。
Sambaの場合は、3つのdaemonがあり、そのうち2つが最低必要である。
Sambaサーバーは以下のdaemonから成り立っている:
このdaemonはすべての名前登録と名前解決要求を処理する。
これはネットワークブラウジング中で必要とされる主要な
伝達手段である。これは、すべてのUDPベースのプロトコル
を処理する。nmbd
daemonはSamba開始
プロセスの一部分として最初にコマンドを起動すべきである。
このdaemonはファイルと印刷関係の操作のための、TCP/IP
ベースのすべてのコネクションサービスを処理する。また、
ローカルでの認証も管理する。これは
nmbd
の開始に引き続いて起動すべきで
ある。
このdaemonはWindows NT4またはADSドメインのメンバーの時に
起動すべきである。また、他のドメインとの信頼関係を結ぶ
時にも必要である。winbindd
daemonは
idmap uid
と
idmap gid
パラメーターがsmb.conf
ファイル中に存在するかどうかをチェックする。もしもそれ
らが見つかった場合、winbindd
はUIDと
GIDの割り当てのために指定された値を使う。もしも、パラメー
タが指定されていなければ、winbindd
は起動するが、UIDとGIDの割り当てが出来ない。
SambaがOSベンダによってパッケージ化されている時、開始プロセスは通常プラッ トフォーム全体に渡って統合された固有の機能となっている。Sambaの起動の正 しい管理に関する特定の情報のためにOSプラットフォームの管理マニュアルを 参照してほしい。
ディストリビューションtarファイル中にのソースコードのexamplesサブディレ
クトリ中にサンプルの設定ファイルがある。実際問題としてオプションがどの
ように組み合わさるかを見る事が出来るので、注意深く読むことを推奨する。
すべてのオプションはマニュアルページを見よ。必要があることに適用するた
めと、smb.conf.default
ファイルを設定し始めること
は価値があるかもしれない。そこには多くのコメントが書いてある。
最も簡単に使える設定ファイルは もう1つ別の簡単なsmb.confファイル 中で見る事ができるようなものを含んでいる。
これは、サーバー上にアカウントを持つ誰でも、ログイン名かサービス名
として、homes
への接続を許す。
(注意:Sambaが使うワークグループ名も設定する必要がある。既定値の
ワークグループ名はWORKGROUPである。)
正しい場所にsmb.conf
ファイルをきちんと置くこと。正しい場所は、
バイナリファイルの構築方法に依存することに注意。正しい場所を知る
ためには、以下のsmbd
コマンド行を実行することで
わかる:
root#
smbd -b | grep smb.conf
[homes]
共有に対するセキュリティ設定の詳しい情報は
Sambaのセキュア化を参照してほしい。
testparmプログラムを使ってsmb.conf
ファイルの内容を検査することは
重要である。もしもtestparmが正しく動けば、設定されたサービスの一覧を
表示する。もしもそうでなければ、エラーメッセージを表示する。それが
正しく動くようにして、動かす前にサービスが合理的であるようにすること。
以下のコマンドを入力する:
root#
testparm /etc/samba/smb.conf
testparmは設定ファイルを解析し、不正な文法や不明なパラメーターを報告する。 また、共通の設定ミスをチェックし、それが見つかれば警告を発する。
smb.conf
ファイルを変更した後には必ずtestparmを実行すること!
smb.conf
ファイルはsmbd
daemonによって定期的にチェッ
クされ、
nmbd
とwinbindd
によりそれがspawnさ
れる毎インスタンスごとにチェックされる。可能な限りこのファイルを小さく
しておくことはよいことである。多くの管理者はSamba設定を文書化すること
を好み、そのため、このファイルを小さくしておくことは、賢明な文書化手法
である。これを適用する1つの解決方法は、
smb.conf.master
というような名前で別のファイルに、
すべての文書と設定を1つにまとめておくことである。
testparm
ユーティリティは、以下のように、マスターの
設定および文書ファイルから完全に最適化されたsmb.conf
ファイルを作成
するのに使える:
root#
testparm -s smb.conf.master > smb.conf
この管理手法は最小限の必要性のためにsmb.conf
ファイルサイズを同じ時に
保つ間詳細な設定変更レコードをメンテナンスすることを可能にする。
SWATはWebベースの、Sambaの設定を行うために使うことが出来るインタフェー スである。SWATはあなたのプラットフォームでSambaパッケージで有効になって いないかもしれないが、分離したパッケージになっているかもしれない。もし もSWATを構築することが必要ならば、編集に注意してSWATのマニュアルページ を読んでソースコードからSWATを構成してインストールしてほしい。
SWATを起動するために、好みのブラウザーを起動し、
http://localhost:901/
を指定する。
Sambaを動かしているコンピュータがブラウザーが動いているコンピュータと異な
るならば、localhost
の部分を置き換えること。
SWATは任意のIP接続されたマシンからブラウザー経由で使えるが、平文でパスワー ドがネットワーク上を流れ、盗聴の危険性があることに注意してほしい。
SWATについての詳細な情報は、 The Samba Web Administration Tool にある。
設定済みのSambaサーバーから有効な共有の一覧を表示するには、以下の コマンドを実行する:
$
smbclient -L
yourhostname
サーバー上で有効の共有の一覧が表示される。もしもそうでなければ、設定が どこか間違っている。この方法はたとえばWindows 2000のような、他のSMB サーバーの共有が有効かと言うことにも使える。
もしも、ユーザーレベルのセキュリティを選択しているならば、共有の一覧を表
示する前にパスワードを要求してくる。詳細はsmbclient
のマニュアルページを参照のこと。コマンドラインに-N
オプションを追加することで、パスワード要求なしに共有の一覧を表示出来る。
以下のコマンドを入力する:
$
smbclient
//yourhostname/aservice
通常yourhostname
はsmbdが
インストールされたホストの名前である。
aservice
はsmb.conf
ファイル中にある任意の
サービスである。smb.conf
ファイル中の
[homes]
セクションがあるならばusernameを試みる
こと。
例:もしもUNIXホストがbambi
で有効な
ログイン名がfred
ならば、以下のように入力:
$
smbclient //
bambi
/fred
Sambaがローカルで正しく動いている時には、他のクライアントからアクセスを 試みることが出来る。数分以内に、Sambaホストは同一のサブネット上のすべて のWindowsクライアント上のマイネットワーク上(Network Neighborhood)に表示 される。他のクライアントからサーバーをブラウズするかそれをマウントするこ とを試みる。
DOS、Windows、あるいはOS/2クライアントからのマウントは以下のコマンドを 動かすことで行える:
C:\>
net use m: \\servername\service
ここで、ドライブ名 m: は任意の有効なドライブ名である。使用するサービス(共有)名を ダブルクリックする時にそれが実際に存在していることは重要である。
印刷システムを試すための例は以下の通り。
C:\>
net use lpt1: \\servername\spoolservice
spoolservice
は対象のサーバー上のプリンターの名前(実際
にはプリントキュー)である。これは、指定されたspoolserviceが所有する
プリンターに送られるWinbowsクライアント上のlpt1:ポートでキャプチャされ
たすべてのプリントジョブを許可する。
C:\>
print filename
Sambaチェックリストを読んでみてもよい。 もしもまだ行き詰まっているならば、 Sambaの問題の解析と解決を参照しよう。 Sambaは世界中でとてもたくさん正常にインストールされている。あなたの 特定の問題が固有であれば、あなたの問題に誰かが遭遇し、それを克服する 方法を見つけていることを発見するために、インターネット上での検索を実 行することは生産的かもしれない。
もしも、Sambaを使うのが初めてで、特にWindowsかUNIX/Linuxののネット ワーキング初心者ならば、“Samba-3 by Example”という本 (訳注:Sambaのドキュメントの一部にもなっている)は評価済みのネットワーク 環境を作るのに手助けとなるだろう。最もサイトのニーズに適合するネット ワークデザインがある最初の五章から単に選び、それを展開するための 単純な段階的手順を取りなさい。その後、ネットワークが動き、更に改良の ための機会のための知識の取得のためには、この本を再度参照しよう。
惨めなフラストレーションのストレスに対する最高のアドバイスは、クールダウ ンすることである!それはそれ自身挑戦かもしれないが、怒っているか、 悩んでいる間、解決策を探すことは難しくなる。頭を冷やせば、探している 答えを見つかることにつながる。繰り返すが、すべての問題は解決策がある 今そうすることが出来なくとも、誰かがそれを見つけるよい機会が ある。それは時間、忍耐と学習で変わる。
少しクールダウンしたなら、 the Samba Checklistを、問題の原因を 確認するために行う事が出来る手順を確認するために参照してほしい。
以下の質問と問題はSambaメーリングリスト上で繰り返し発生するものである。
Sambaの3つの中心的なプログラムは:nmbd, smbd, と winbinddである。 nmbdはネームサーバーメッセージdaemonで、smbdはサーバーメッセージ daemonで、winbinddはドメインコントローラーとの間での通信を処理する daemonである。
もしもSambaがWINSサーバーとして動作していないならば、 システム上には1つのnmbdインスタンスが動作する。もしもWINSサーバーとして 動作するならば、2つのインスタンスがある。1つはWINS要求を処理 する。
smbd はすべての接続要求を処理する。おのおののクライアントに対する 接続が終わると新しいプロセスがspawnする。それゆえ、クライアント接続毎 にたくさんのdaemonが存在する。
winbinddは1つまたは2つのdaemonで動作し、 split mode(2つのインスタンスの場合)かどうかによる。
smbdが起動した時にログファイル中に以下のエラーメッセージが出ることがある: “open_oplock_ipc: Failed to get local UDP socket for address 100007f. Error was Cannot assign requested.”
これは、loopbackデバイスが正しく動作していない。正しく設定し直すこと。 ループバックデバイスは内部(仮想の)ネットワークデバイスで、IPアドレスが 127.0.0.1である。システム上でどのようにloopback デバイスを設定するかはOSのドキュメントを読むこと。
Table of Contents
Samba HOWTO文書中に含めるものについての最初に提案を受けた時、 だれかが問い合わせのためのサンプル設定をたくさん書いた。これは、 動いているシステムからたくさんのエッセンスを提示することに由来するたくさんの 価値を失わないで行う事が甚だしく難しい。それがドキュメントに抜けているもので ある。それをカバーする章の内容の中に設定の可能性の広範囲な説明がある。この 章は、要求されたことに対する処方であると思いたい。
この章中の情報は、ほとんど完成したこの本のオリジナルバージョンの後に書かれた “Samba-3 by Example”という本と比較してかなり情報量が少ない。 “Samba-3 by Example”は最初の版の最終稿をレビューした結果を フィードバックしたものである。読者フィードバックが、オリジナルのレビュアによ り反映が行われることを見ることは興味深かった。どの場合にも、経験ある ネットワーク管理者がそこから得るものと同様、何が新しいかをより理解する ための基礎的な調査に1ヶ月半かかった。“Samba-3 by Example”は その調査の結果である。この本のいくつかのページで提供されているものは、より 包括的に“Samba-3 by Example”の第二版でカバーしている。 両者の第二版は同じ時期にリリースされた。
まとめると、“公式のSamba-3 HOWTO & リファレンスガイド”は 自動車修理工の修理ガイドと同等のものとして意図されている。 “Samba-3 by Example”は、どのように車を運転するかを説明する ドライバー向けのガイドと同等である。もしもネットワークの設定例を完全にしたい のであれば、 Samba-3 by Exampleを参照すること。
基本的な動作するシステムを作成するために、Sambaは最小限の設定しか必要としない。 この節では、簡単なものから複雑なものへ、おのおのを動かすために必要とされる 設定ファイルの変更とすべてのステップを順番に提供する。徹底的に設定された システムは、追加の高機能な機能を使うだろう。それらの追加機能はこの文書の 残りの部分で触れられている。
ここで使っている例は、数多くの人が設定の例のために要求したものに依っている。 すべての識別子は問題がないようにしてあり、非現実的な存在しないサイトへ 何らかの形で似ていることは計画的に行われている。
最初の設定例中では、例外的な、簡単なシステム要求の場合を考えてみる。 ほとんど取り組みを必要としないものを複雑にしようとする真の誘惑がある。
“匿名リードオンリ文書サーバー” はCD-ROMイメージを提供するのに十分かも しれないサーバーのタイプか、ネットワーククライアントが使う用途向けの参考 文書を提供する。この設定は “スタンドアロンサーバー”、“参照用文書サーバー” でも取り上げている。この設定の目的は、ゲストも含めて誰でもリードオンリで アクセスできる共有ボリュームを提供することである。
2番目の例は、コンピュータ上にインストールされた正しいプリンタードライバーを 持つのと同じくらい長く、誰でも印刷できるプリントサーバーのための最低限の 設定である。これは “スタンドアロンサーバー”, “集中印刷サーバー” で説明されているものと同じである。
次の例は、システム上にアカウントを持つユーザーのみがアクセス可能な、安全な オフィス用ファイル/プリントサーバーである。このサーバーはワークグループの ファイル/プリントサーバーととてもよく似ているが、匿名でアクセスするマシンより はより安全である。このタイプのシステムは、一般的に小さなオフィスの用途に 適合している。サー派はネットワークログオン機能、ドメイン制御を提供しない。 その代わりにネットワーク経由のストレージデバイス(NAS)とプリントサーバーである。
最後の例は存在するMicrosoft Windowsネットワークを統合するか、それを完全に 置き換えるより複雑なシステムである。これらはSambaドメイン制御(PDC/BDC)と 同様なドメインメンバーサーバーとリモートの場所中にあるブランチオフィスでの、 大きな分散ネットワーク中で詳細が説明されるものをカバーする。
設定の例はSambaが動くために必要なすべてをカバーするためにデザインされている。 それはこのテキストの範囲を明らかに超えている、基本的なOSプラットフォームの 設定をカバーしていない。
また、OSベンダによって提供されているパッケージにか、他の手段で Sambaが正しくインストールされていることも仮定している。
スタンドアロンサーバーであるということは、それがドメインコントローラーでないこと、 ドメイン制御下に参加していないと言う事実以上のことを何も暗示しない。これは 単純で、ワークグループ風のサーバーであるか、ドメインセキュリティ管理下のメンバー であることができる。
例題が作成されている間、真のビジネスオフィスが、そのオフィスの大きさが 増えたり必要に応じて変わるようなことが起こると思うかもしれないのと同じ ように、システムが、そのすばらしい能力に向かって進歩するすべての試みが行 われた。
このタイプのサーバーの目的は、共有リソース上にある任意の文書やファイルを 任意のユーザーに有効にさせることである。共有リソースはCD-ROMでもファイル 領域でも可能である。
ファイルシステムの共有位置は/export
である。
すべてのファイルはJack Baumbachと呼ばれるユーザーが所有している。 Jackのログイン名はjackbである。そのパス ワードはm0r3pa1nである。 もちろんこれは例として使っているものである。すべての、この 文書の読者がこのことを知っているため、実環境でこれを使っては いけない。
Procedure 2.1. インストール手順: リードオンリサーバー
ユーザーをシステムに登録する(ユーザーのホームディレクトリも作る):
root#
useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb
ディレクトリを作りパーミッションと所有者を設定する:
root#
mkdir /export
root#
chmod u+rwx,g+rx,o+rx /export
root#
chown jackb.users /export
/export
ディレクトリに共有したいファイルをコピーする。
匿名リードオンリサーバー設定で
表示されているSamba設定ファイル(/etc/samba/smb.conf
)を
インストールする。
以下のコマンドを実行して設定ファイルをテストする:
root#
testparm
代替として、smb.conf.master
と呼ばれるマスター
設定ファイルから操作している場合、以下のコマンドシーケンスの方が
より適切である:
root#
cd /etc/sambaroot#
testparm -s smb.conf.master > smb.confroot#
testparm
何らかのエラーメッセージが出力されるかもしれないことに注意。 エラー出力がない場合にのみ先に進むこと。上記の設定ファイルで 生成される典型的な出力の例は以下の通り:
Load smb config files from /etc/samba/smb.conf
Processing section "[data]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[Press enter]
# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = share
[data]
comment = Data
path = /export
read only = Yes
guest only = Yes
OSプラットフォームに適した方法でSambaを起動する。その方法は プラットフォーム依存である。Sambaを起動することに関するそれ 以上の情報は、Starting Samba を参照のこと。
Microsoft Windowsクライアントをワークグループ
MIDEARTHに設定し、コンピュータ名を
ROBBINSに設定し再起動し、数分待ち、Windowsエクスプローラー
を開いてマイネットワークをクリックする。そこにマシンHOBBIT
がある。このマシンアイコンをクリックすると、
data共有が現れる。共有をクリック後、
/export
ディレクトリ中にある、以前に
そこにおいたファイルが現れる。
上記の情報(#グローバルパラメーター以下)は
/etc/samba/smb.conf
ファイルの完全な内容を提供
する。
以前の例からこの設定を発展系と見なすべきである。違いは、共有アクセスが
jackbというユーザーIDに、プライマリグループがjackbに強制的に設定されると
いうことである。その他1つの改善点は、ユーザーjackbを
smbpasswd
に追加することが出来るということである。
これを行うのには以下を実行する:
root#
smbpasswd -a jackb
New SMB password:m0r3pa1n
Retype new SMB password:m0r3pa1n
Added user jackb.
smbpasswd
ファイルへのこのユーザーの追加は、エクス
プローラのプロパティにおいて所有者がUser Unknown
の代わりにjackbが表示されると言うことである。
完全な変更後のsmb.conf
ファイルは“変更後の匿名の読み書き可能な設定の smb.conf”である。
1つの所から、すべてのプリンターに印刷を許可する。
制限された数のプリンターに対するアクセスのため、たくさんの ユーザーのためにネットワークのトラフィックの輻輳を減らす。
最も単純な匿名印刷サーバー中で、Windowsワークステーション上での正しい プリンタードライバーのインストール要求は共通である。この場合、プリント サーバーはスプーラに対して印刷ジョブを単に渡すだけに設定され、 スプーラはプリンターに対して素通しになるように設定される。別の言い方 をすると、プリントスプーラはプリンターに対して渡されたデータストリーム をフィルタリングもなんらかの処理もしない。
この設定中で、プリンターの追加ウィザードを使うのは好ましくなく、
また、自動ドライバーダウンロードを行うのも望まない。そのため、
以下の設定でそれを無効にする。
“匿名プリントサーバーのsmb.conf”は結果の smb.conf
ファイルである。
上記の設定は理想的なものではない。よりよい機能を使っておらず、
故意にエレガントではない解決方法を提示している。しかし、これは
基本であり、これで印刷は出来る。SambaはCUPSによって提供される
直接印刷APIを使える。CUPSライブラリを、Sambaコンパイル時に指定
してリンクした場合、既定値の印刷システムはCUPSになる。princap name
がCUPSを指定した場合、Sambaはすべての印刷機能のためにCUPSに直接
通信を行うため、CUPSライブラリAPIを使う。
printing
の値をSYSVかBSDに設定して外部印刷
コマンドを強制的に使うことが可能で、パラメーター
printcap name
の値はCUPS以外の何かに設定
しなければならない。この場合、Windowsクライアントに対して有効に
させるためのプリンターの一覧が含まれている任意のファイルの名前を設定
する。
Windowsユーザーはローカルプリンターのインストールが必要で、ドライバーの インストール後に通常使うプリンターを切り替える。通常使うプリンターは そのマシン上のネットワークプリンターに設定できる。
ディレクトリ/var/spool/samba
が使えるように
なっていることを確かめておくこと。以下の手順はこれを達成するため
に行わなければならない:
ディレクトリはスーパーユーザー(root)のユーザーとグループに属さねば ならない:
root#
chown root.root /var/spool/samba
ディレクトリのパーミッションは以下のようにスティッキービット を設定して「その他」をRWに設定しなければならない:
root#
chmod a+twrx /var/spool/samba
スティッキービット設定の目的は、一時印刷ファイルを所有していない ユーザーが誤用で制御を得てしまう可能性を防止するためである。
CUPSが有効になっているシステムで、中間のCUPSプリントフィルタ処理なしで、
直接プリンターに生データを渡す機能がある。このモードの操作を使うことが
要求される場合、生データを印刷するデバイスを設定することが必要である。
また、/etc/mime.conv
と
/etc/mime.types
ファイル中のraw mime ハンドラーを
有効にする必要もある。“application/octet-streamのためのraw印刷を明示的に有効にする”を参照のこと。
続いて、簡単なシステムからやや複雑なサーバーの例に説明を進めよう。
新しいサーバーは認証されたユーザーのみ(すなわち、ローカルアカウントを持つ)が、 ホームディレクトリと同様にファイルを保存できる共用データ領域を必要とする。 また、誰でも使える1つのプリンターも提供する。
この仮想の環境(このデータを入手するための盗聴は無いものとする)中で、 使うのに難しくない、十分な安全性を持つ簡単な環境に サイトは依存する。
サイトユーザーは Jack Baumbach, Mary Orvilleと Amed Sehkahである。おのおのは パスワード(これ以降の例では表示しない)を持つ。Maryはプリンター管理者で、 共通の共有中のファイルの所有者である。
この設定は既定値であるユーザーレベルのセキュリティを
ベースとしていて、/etc/samba/smbpasswd
中に
Windows互換の暗号化パスワードを格納している。この設定にするための既定値
のsmb.conf
エントリは
passdb backend = smbpasswd, guestである。
これが既定値になっているので、設定ファイルにこれを記述する必要はない。
guest バックエンドはSamba設定ファイル中で指定されるか否かに関わらす、
有効なpassdb backendに追加されることに注意。
Procedure 2.2. セキュアなオフィスサーバーのインストール
Example 2.4. セキュアなオフィスサーバーのsmb.conf
root#
useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb
root#
useradd -c "Mary Orville" -m -g users -p secret maryo
root#
useradd -c "Amed Sehkah" -m -g users -p secret ameds
“セキュアなオフィスサーバーのsmb.conf”中で示されているようにSambaの smb.conf
を設定する。
Microsoft Windowsパスワードデータベースに新規ユーザーを追加する:
root#
smbpasswd -a root
New SMB password:bigsecret
Reenter smb password:bigsecret
Added user root.root#
smbpasswd -a jackb
New SMB password:m0r3pa1n
Retype new SMB password:m0r3pa1n
Added user jackb.root#
smbpasswd -a maryo
New SMB password:secret
Reenter smb password:secret
Added user maryo.root#
smbpasswd -a ameds
New SMB password:mysecret
Reenter smb password:mysecret
Added user ameds.
CUPS Webインタフェースを使ってプリンターをインストールする。生データを 印刷するデバイスとしてMicrosoft Windowsクライアントで共有するプリンター をインストールするようにすること。
OSの管理インタフェースを使ってSambaを起動する。それは以下の方法でも 手動で可能である:
root#
nmbd; smbd;
両方のアプリケーションは自動的にdaemonとして動く。daemonモードで開始
することを強制する、パラノイド的な-D
フラグを追加
することも可能である。
/export
ディレクトリを設定する:
root#
mkdir /export
root#
chown maryo.users /export
root#
chmod u=rwx,g=rwx,o-rwx /export
Sambaが正しく動いているかを調べる:
root#
smbclient -L localhost -U%
Domain=[MIDEARTH] OS=[UNIX] Server=[Samba-3.0.20] Sharename Type Comment --------- ---- ------- public Disk Data IPC$ IPC IPC Service (Samba-3.0.20) ADMIN$ IPC IPC Service (Samba-3.0.20) hplj4 Printer hplj4 Server Comment --------- ------- OLORIN Samba-3.0.20 Workgroup Master --------- ------- MIDEARTH OLORIN
以下のエラーメッセージはSambaが動作していないことを示している:
root#
smbclient -L olorin -U%
Error connecting to 192.168.1.40 (Connection refused)
Connection to olorin failed
ユーザーmaryoでOLORINに接続する:
root#
smbclient //olorin/maryo -Umaryo%secret
OS=[UNIX] Server=[Samba-3.0.20] smb: \>dir
. D 0 Sat Jun 21 10:58:16 2003 .. D 0 Sat Jun 21 10:54:32 2003 Documents D 0 Fri Apr 25 13:23:58 2003 DOCWORK D 0 Sat Jun 14 15:40:34 2003 OpenOffice.org D 0 Fri Apr 25 13:55:16 2003 .bashrc H 1286 Fri Apr 25 13:23:58 2003 .netscape6 DH 0 Fri Apr 25 13:55:13 2003 .mozilla DH 0 Wed Mar 5 11:50:50 2003 .kermrc H 164 Fri Apr 25 13:23:58 2003 .acrobat DH 0 Fri Apr 25 15:41:02 2003 55817 blocks of size 524288. 34725 blocks available smb: \>q
ここまでのことで、設定の基礎を会得したかと思う。これからはより複雑な 例を見ていく。この節の残りの部分は、いままでの例で説明した手順の部分 は省略する。
ここでは、経理部門が幸せにできるような、最も簡単なサーバー設定を題材にする。ユーザーは 会計担当で、小難しい要求をしてくることに注意しよう。この部門のために1台のサーバー予算 がある。
ネットワークは社内情報サービスグループ(Information Services Group (ISG))で管理され、そこ に所属しているものとする。内部の製作は典型的な中規模の組織である。いつでもユーザーの追加削 除を行っているという理由でISGを運営しているのがHuman Resources is of the opinion。 また、スタッフのために基本的なネットワークリソースアクセスを得るために、部門の管理者は 死力を尽くして戦わなければならない。けれども経理部門は違い、彼らは正確に彼らがほしい ものを手に入れる。そのため、これは場面を設定すべきである。
ここでは最後の例からのユーザーを使うことにする。経理部門にはその部門のユーザーが使える 汎用プリンターがある。また、小切手を印刷するための権限を持つ人のそばにその人だけが 使える小切手印刷プリンターもある。最高会計責任者(CFO)はオフィス内の個人用収納場所 中に配置して完全にそのプリンターの使用を制限したいと望んでいる。そのため、それは ネットワークプリンターである必要がある。
経理部門は中央のアプリケーションサーバーから動かさなければならない SpytFullという会計アプリケーションを使っている。ソフトウェア は1台のサーバーだけで動かすようにライセンスされていて、底にはワークステーション コンポーネントがなく、マップされた共有で動く。データはUNIXベースのSQLバックエンド にある。UNIXの専門家はそれをみて、それはUNIX屋の問題ではないと言う。
経理部門のマネージャ(maryo)はフォームレター(いやなメール)のために分離したファイル 格納領域と同じような汎用ファイリングシステムを希望している。フォームレター領域は マネージャを除いてすべての経理スタッフにはリードオンリにすべきである。汎用ファイ リングシステムは、経理のチームのメンバーの、その人固有の階層構造ファイル領域を持つ 必要があるが、マネージャにはすべての領域にアクセスできることを希望している。各 ユーザーは、個人に関連したファイルのための固有のホーム領域を持つが、それは部門の 作業に関連しない。
サーバーvalinorは会社のドメインのメンバーサーバーである。 経理部門はローカルサーバーのみを持つ。ユーザーのアカウントはドメインコント ローラ上にあり、そこにはデスクトッププロファイルとすべてのネットワーク ポリシファイルがある。
Example 2.6. メンバーサーバーのsmb.conf (Shares and Services)
UNIX/Linuxサーバーにユーザーを追加してはならない。すべては中央の ドメインで行う。
メンバーサーバーのsmb.conf
(globals)と
メンバーサーバーのsmb.conf (shares
and services)と一致するようにsmb.conf
を設定する。
ドメインに参加する。注意:このステップが終わるまでSambaを起動してはいけない!
root#
net rpc join -Uroot%'bigsecret'
Joined domain MIDEARTH.
winbind
が設定されて動いている任意のシステム上で
nscd
daemonを停止する(シャットダウンする)ことを必ず行うこと。
OSプラットフォームの通常の方法で、Sambaを起動する。 手動で動かしたい場合は、rootになって以下の手順で起動する:
root#
nmbd; smbd; winbindd;
winbind経由でユーザーとグループ名を解決するために、システム上にあるネーム
サービススイッチ(NSS)制御ファイルを設定する。
/etc/nsswitch.conf
中の以下の行を編集する。
passwd: files winbind group: files winbind hosts: files dns winbind
wbinfo
に対するパスワードを以下の方法で設定する:
root#
wbinfo --set-auth-user=root%'bigsecret'
ドメインユーザーとグループの認証が以下を実行することで正しく解決されるかを 検証すること:
root#
wbinfo -u
MIDEARTH\maryo MIDEARTH\jackb MIDEARTH\ameds ... MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain Users MIDEARTH\Domain Admins MIDEARTH\Domain Guests ... MIDEARTH\Accounts
winbind
が動作しているかをチェックすること。以下は、
getent
システムユーティリティ経由で正しいユーザー名の
解決を行っている例である:
root#
getent passwd maryo
maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
A final test that we have this under control might be reassuring:
root#
touch /export/a_file
root#
chown maryo /export/a_file
root#
ls -al /export/a_file
... -rw-r--r-- 1 maryo users 11234 Jun 21 15:32 a_file ...root#
rm /export/a_file
ここまでで設定はほぼ終わり、この後、このサイト用にディレクトリ 構造を設定する:
root#
mkdir -p /export/{spytfull,public}
root#
chmod ug=rwxS,o=x /export/{spytfull,public}
root#
chown maryo.Accounts /export/{spytfull,public}
この節の残りの部分は、ドメイン制御の設定に焦点を当てる。以下は2つの実装方法の例である。 ここでの例は、簡単に作れるが、ちゃんと動くものを提示するのが目的であることを思い出して ほしい。この本の残りではより大きな機能性とそれに付随する複雑性に注目する機会を手助け するべきである。
ドメインコントローラーの設定は新しいtdbsamパスワードバックエンドを使う簡単な設定 で達成できる。このタイプの設定は小さなオフィスに適しているが、拡張性が制限され ていて(複製が出来ない)、ドメインの大きさと複雑さが増大するとパフォーマンスが 下がることが予想される。
tdbsamの使用は、PDC以外の必要性がないサイトにのみ最適である。ドメインが大きく なると、追加のドメインコントローラーが必要となるのは必定である。Microsoftネット ワーク環境に過小なリソースを提供しようと試みてはいけない;ドメインコントローラーは 基本的な認証サービスを提供する。以下は過小なリソースでのドメインコントロール 環境の症状である:
ドメインログオンが断続的に失敗する。
ドメインメンバーサーバー上のファイルアクセスが断続的に失敗し、 パーミッション拒否エラーメッセージが出る。
より拡張性のあるドメインコントロール認証バックエンドオプションは、 Microsoft Active DirectoryかLDAPベースのバックエンドを使うことである。 Samba-3はドメインメンバーサーバーとして両方のオプションを提供する。PDC として、Samba-3はActive Directoryで有効な機能の完全な代替を提供でき ない。Samba-3は拡張性のあるLDAPベースの PDC/BDCソリューションを提供 できる。
tdbsam認証バックエンドは、外部手段を除いて、データベースの内容を複製 する機能は提供していない(すなわち、独立したSamba-3のためのSAM複製 手順はない)。
もしも1つ以上のドメインコントローラーが必要ならば、tdbsam認証バックエンドは 使えない。
ここで提供するエンジニアリングオフィスのネットワークサーバーは、新しい tdbsamパスワードバックエンドの使い方をデモするように設計されている。 tdbsam機能はSamba-3で取り入れられた。Microsoft Windows NT4で可能な たくさんのユーザーとマシンアカウント制御を提供するように設計された。 小さなネットワーク中で使うのには、これは安全である。
Example 2.7. エンジニアリングオフィスのsmb.conf (globals)
Example 2.8. エンジニアリングオフィスのOffice smb.conf (shares and services)
tdbsamパスワードバックエンドを使う動作するPDCの設定は、 エンジニアリングオフィスのsmb.conf (globals)と エンジニアリングオフィスのsmb.conf (shares and services)にある:
OSで提供されているツールを使って、必要に応じUNIXグループを作成する:
root#
groupadd ntadmins
root#
groupadd designers
root#
groupadd engineers
root#
groupadd qateam
OSで提供されている適当なツールを使ってシステム上にユーザーアカウントを 作成する。同時にユーザー毎のホームディレクトリを作っておくこと。Samba 環境で使うときに要求されるグループのファイル、ディレクトリ、プリンター のアクセス制御に対し、ユーザーを追加する。
このシェルスクリプトを動かしてNTグループにおのおののUNIXグループを割り当
てる(スクリプトの名前はinitGroups.sh
とする)。
#!/bin/bash #### Keep this as a shell script for future re-use # First assign well known groups net groupmap add ntgroup="Domain Admins" unixgroup=ntadmins rid=512 type=d net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type= net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d # Now for our added Domain Groups net groupmap add ntgroup="Designers" unixgroup=designers type=d net groupmap add ntgroup="Engineers" unixgroup=engineers type=d net groupmap add ntgroup="QA Team" unixgroup=qateam type=d
[NETLOGON]
共有中で使うための
scripts
ディレクトリを作成する:
root#
mkdir -p /var/lib/samba/netlogon/scripts
使用するログオンスクリプト(バッチまたはcmdスクリプト)をこの ディレクトリに配置する。
上記の設定で、ファイル共有とプリンター共有を必要に応じて追加しなければ ならない、基本的なPDCシステムが提供される。
この節では、LDAPベースの認証バックエンドを使うSamba-3の設定の簡単な 紹介を行う。このことを行う主旨は、より高次のレベルのスケーラビリティ に適合するのを可能にするための、とても分散した環境と同じように、 PDC/BDCホストを可能にすることを提供することである。
これは、LDAP認証バックエンドを使うSamba-3 PDCを動かすための 最小限の設定例である。OSが正しく設定されていることを仮定して いる。
Idealx スクリプト(か同等のもの)が、LDAPベースのPOSIXとSambaSamAccount
を管理するのに必要である。Idealxスクリプトはサイト
Idealxからダウンロードする
ことが出来る。また、Sambaのリリースtarファイルから得ることも出来る。
Linuxディストリビューションは、Idealxスクリプトを
/usr/share/doc/packages/sambaXXXXXX/examples/LDAP/smbldap-tools
ディレクトリにインストールする傾向がある。
Idealxスクリプトバージョンsmbldap-tools-0.9.1
は
よく動作することが知られている。
Example 2.9. PDC用のLDAPバックエンドを使うsmb.conf
Sambaのソース~/examples/LDAP/samba.schema
から入手し、/etc/openldap/schema/
ディレクトリにそれをコピーする。
LDAPサーバーを設定する。この例はOpenLDAP 2.1.xに対応している。
The /etc/openldap/slapd.conf
file.
<title>Example slapd.conf File</title>
# Note commented out lines have been removed include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args database bdb suffix "dc=quenya,dc=org" rootdn "cn=Manager,dc=quenya,dc=org" rootpw {SSHA}06qDkonA8hk6W6SSnRzWj0/pBcU3m0/P # The password for the above is 'nastyon3' directory /var/lib/ldap index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub
# Organization for SambaXP Demo dn: dc=quenya,dc=org objectclass: dcObject objectclass: organization dc: quenya o: SambaXP Demo description: The SambaXP Demo LDAP Tree # Organizational Role for Directory Management dn: cn=Manager,dc=quenya,dc=org objectclass: organizationalRole cn: Manager description: Directory Manager # Setting up the container for users dn: ou=People, dc=quenya, dc=org objectclass: top objectclass: organizationalUnit ou: People # Set up an admin handle for People OU dn: cn=admin, ou=People, dc=quenya, dc=org cn: admin objectclass: top objectclass: organizationalRole objectclass: simpleSecurityObject userPassword: {SSHA}0jBHgQ1vp4EDX2rEMMfIudvRMJoGwjVb # The password for above is 'mordonL8'
LDAPデータベース中に初期データを投入する:
root#
slapadd -v -l initdb.ldif
OSにインストールされている方法か適当なツールを使ってLDAP サーバーを起動する。
/usr/local/sbin
ディレクトリ中にIdealx
スクリプトファイルをインストールし、システム設定に合わせて、
smbldap_conf.pmを設定する。
このバックエンドを制御するsmb.conf
ファイルの例は
PDC用のLDAPバックエンドを使うsmb.conf
にある。必要に応じて追加する。
secrets.tdb
ファイルにLDAPパスワードを
追加すると、SambaはLDAPデータベースを更新できるようになる:
root#
smbpasswd -w mordonL8
必要に応じてユーザーとグループを追加する。Sambaツールを使った ユーザーとグループの追加は必要に応じて、自動的にLDAPバックエ ンドとOSに追加される。
“リモートのLDAPを使うBDCのsmb.conf” ではBDCの設定例を示している。smb.conf
ファイルがBDC上で必要でないsmbldap-toolsスクリプトを
指定していないことに注意。必要に応じて追加の共有とプリンターを
追加する。
Example 2.10. リモートのLDAPを使うBDCのsmb.conf
BDCが固有のLDAPサーバーを持つかどうかを決める。もしもBDCが
LDAPサーバーであるならば、以下のsmb.conf
を示されたように
変更する。既定値の
リモートのLDAPを使うBDCのsmb.conf
中の設定は、中央のLDAPサーバーを使う。
“リモートのLDAPを使うBDCのsmb.conf”中にあるようにNETLOGONとPROFILES ディレクトリを設定する。
SambaはSMBネットワーク内でいろいろなモードで操作することができる。このHOWTOセクションは ネットワークが必要とするサーバーのタイプとして機能するようにSambaを設定する情報を含んでい る。注意深くこのセクションを読んでほしい。
Table of Contents
この章では、Sambaで設定可能なサーバーのタイプに関する情報を提供する。Sambaへのマイグレーションか、 単に使いたいと思っているMicrosoft ネットワーク管理者は、Microsoft Windows管理者にわかりやすい 言葉で、Sambaの文脈においてその意味を知りたいはずである。これは、サーバーそれ自身をどのように 設定するかという詳細を得る前に重要なセキュリティモードの機能を定義すると同様に重要であること を意味する。
この章では、Microsoftサーバーとクライアントにどのように関連することと、Sambaのセキュリティモードが できることについての概要を提供する。
しばしば聞かれる質問は、“なぜSambaを使うのか”である。ほとんどの章は、機能と利便性 に注目した節を含んでいる。情報がこの質問に答える手助けを提供することを希望している。しかし、 我々は公正で合理的であることを望むので、すべての機能がSambaに対して好ましいとは限らないことを 警告する。利便性は競合他社の方にあるかもしれない。
2人の人が汚れた道を歩いていたとき、1人が突然小さな赤い石を蹴飛ばした。それは 彼のつま先を傷つけ、サンダルに突き刺さった。彼は石を取り去り、苦しみと激怒 のあまりののしった。もう1人は石を見て、“これはガーネットだ。これを 貴重な宝石に変えられる。そして、いつの日かこれはプリンセスを非常に幸福に するだろう!”
この物語の教訓:2人の人は同じ石に対して2つの非常に異なった観点を持っていた。それと 同じかどうかにかかわらず、Sambaはその石と似ている。正しく扱えばとても優れた宝物に なるが、それに関わる時間を持つことが出来ないことを強いられるならば、それは非常に 不愉快なものになる。
SambaはUNIXサーバーとMicrosoft Windows 3.xクライアントのための相互運用性を提供する ためのプロジェクトとして開始された。それは、ささやかなスタートから大きく成長し、 いまや巨大システムに適合する機能を提供するようになった。しかし若干の問題点も ある。このような節ではその両方について触れる。
そのため、この章で説明されている機能の利点は何であろうか?
Samba-3はネイティブのMicrosoft Active Directoryドメインと同じように NT4スタイルのMicrosoft Windows NT4スタイルのドメインとのすぐれた相 互運用性を提供する。
SambaはMicrosoft Windows NT4ドメインコントローラーで出来るよりも より柔軟性のある認証機能を許可するセキュリティモードを持っている。
Samba-3は複数の同時アクセス可能なアカウントデータベースバックエンドを 使える(暗号化パスワードはWindowsネットワーキングのために固有となる形 式でアカウントデータベース中に格納される)。
アカウントデータベースバックエンドは複数の方法で複製され配布される。 これは、Samba-3がMicrosoft Windows NT4よりもより優れた柔軟性を与え、 多くの場合、Microsoft Windows 200xのActive Directory ドメインよりも かなり便利なユーティリティとなる。
Microsoftネットワークの管理者はしばしば3つの異なったタイプのサーバーを参照する:
ドメインコントローラー
Primary Domain Controller (PDC)
Backup Domain Controller (BDC)
ADS Domain Controller
ドメインメンバーサーバー
Active Directory Domain Server
NT4 Style Domain Domain Server
スタンドアロンサーバー
ドメイン制御を扱っている節(ドメイン制御), バックアップのドメイン制御(バックアップドメイン制御),と ドメインメンバーシップ(ドメインメンバーシップ)は 3つのサーバーの役割のためのSambaの設定に言及する適切な情報を提供する。Sambaドメイン セキュリティの実装のための基礎を作るために、それらの章のそれぞれについて、精通 しておくことを強く推奨する。
スタンドアロンサーバーはアカウント管理が独立している。スタンドアロン サーバーとして設定することがサーバーにとって何を意味するかについてのより広い評価を 得るために、スタンドアロンサーバーを参照のこと。
この節では、Sambaのセキュリティモードの機能と目的について説明する。おのおののモードの ためにMicrosoft Windows クライアントを設定する方法と同様におのおののセキュリティモード についてどのようにSambaが実装しているかを正確に理解することは、ユーザーの不満と管理者の 心労をとても減らすだろう。
Microsoft Windows ネットワークはもともとServer Message Block(SMB)プロトコルと 呼ばれていたプロトコルを使っている。1996年あたりから、プロトコルは Common Internet Filesystem(CIFS)プロトコルとしてより知られるようになった。
SMB/CIFSネットワークにおいては、ユーザーレベルと 共有レベルという2つのセキュリティのみがある。それらをまとめて セキュリティレベルとして参照する。それら2つのセキュリティレベル の実装において、SambaはMicrosoft Windows NT4/200xサーバーでは出来ない柔軟性を提供する。 実際、Sambaは共有レベルのセキュリティを1つの方法で実装しているが、 ユーザーレベルのセキュリティについては4つの方法で実装している。 それらをまとめて、Sambaでのセキュリティレベルの実装を セキュリティモードと呼ぶ。それらは、 share, user, domain, ADSとserverモードとして知られている。 それらはこの章で解説されている。
セッションのセットアップ時にクライアントに対してSMBサーバーは動作しているサーバーの セキュリティレベルを伝える。それはシェアレベルとユーザーレベルという2つのオプション である。2つのうちのどちらかをクライアントが受け取り、それは、クライアントがそれ 自身を認証するときに試みる方法に影響する。それはSambaサーバーをセキュリティ化する 方法には直接(たいして)影響しない。これは奇妙に聞こえるが、それはSMBのクライアント/ サーバーアプローチに適合する。SMB中では、すべてはクライアントによって開始され、 制御され、サーバーはクライアントに対して、何が有効で、どのような動作が許可されるか のみを通知できる。
client
という語は、たとえばWindowsワークステーション、Windows
サーバー、あるいはその他の平凡なSMBまたはCIFSクライアントアプリケーション(たとえば
smbclient
)のような、SMB/CIFSサーバーによって提供されるサービスを
使うものすべてのエージェントを参照する。
それが簡単なため、最初にユーザーレベルのセキュリティを説明する。ユーザーレベルの セキュリティでは、クライアントはプロトコルネゴシエーションを伴って、直接 セッションセットアップ要求を送信する。この要求はユーザー名とパスワードを提供 する。サーバーはそのユーザー名/パスワードペアを受け取るか拒否するかのどちらか を行う。この段階で、サーバーはクライアントが結局接続しようと試みる共有が 何であるかを知るすべはなく、そのため、許可/拒否 について、以下の2つ以外をベースと出来ない:
ユーザー名/パスワード ペア
クライアントマシンの名前
もしもサーバーがユーザー名/パスワードペア認証を許可するならば、クライアントは、 その先パスワード指定なしで(tree connectionを使って) 共有をマウントできることを仮定する。クライアントは、すべてのアクセス権限が 最初のsession setup中で指定したユーザー名/パスワード認証 セットであることを仮定する。
複数のsession setup要求をクライアントが送信することも 可能である。サーバーが返信するとき、そのユーザー名/パスワードペアのための、 認証タグとして使うために、uidを送る。クライアントは この方法で複数の認証コンテキストを操作することが可能である(このことを行う アプリケーションの例としてはWinDDがある)。
Windowsネットワークユーザーアカウント名は大文字小文字に依存しない。すなわち、 アカウント名中の大文字小文字はすべて同一視されると言うことである。また、 大文字小文字の状態は保存されるが、大文字小文字の状態は関係ないということ である。Windows NT 3.10より前のWindowsとLanManagerシステムは、大文字小文字 の状態を保存する必要がない、大文字小文字を無視するパスワードを使っていた。 すべてのWindows NT ファミリシステムはパスワードについて、大文字小文字を保 存し、それを意識するように取り扱う。
共有レベルのセキュリティ中では、クライアント自身の認証はおのおのの共有毎に 分離している。クライアントはおのおのの tree connection要求(共有マウント) と共にパスワードを送るが、この操作で明示的にユーザー名を送らない。クライアント は、おのおのの共有にパスワードが関連づけられ、ユーザーから独立していることを 期待する。これは、Sambaは、ユーザー名がSMBサーバーに明示的に送られないために、 クライアントが使いたいとしているユーザー名をSambaが考えなければならないこと を意味する。たとえばNTのような、いくつかの商用SMBサーバーは共有レベルの セキュリティ中に直接共有とパスワードを関連づけるが、Sambaはいつでも、 共有/パスワードペアではなく、認証に使ったユーザー名/パスワードペアを使う UNIX認証スキームを使う。
Microsoftネットワーキングとの類似点を理解するために、パスワードあり/なし でリードオンリまたはフルアクセスできる共有フォルダーを作成できる、Microsoft Windows 9x/Meについて考えてみる。
多くのクライアントは、サーバーが共有レベルのセキュリティであったとしても、
session setup要求を送る。それらは通常有効なユーザー名を送るがパスワードは
送らない。Sambaは有効なユーザー名リスト中にこのユーザー名を記憶する。クライアント
がtree connection要求を次に発行するとき、接続しようとする共有名の名前
(ホームディレクトリに有用)をこのリストに追加もし、smb.conf
ファイル中の
userパラメーター中にリストされているユーザーもである。
次にパスワードが、それらの可能なユーザー名に対して順番にチェックされる。
もしも一致したものが見つかれば、クライアントはそのユーザーとして認証される。
使用可能なユーザー名のリストが提供されていない場合、Sambaは、標準のアカウント
データベースから、そのユーザーに対して提供されるパスワードとユーザーアカウントを
UNIXのシステムコールを使って探し出すことを行う。システムがネームサービススイッチ
(NSS)機能を持っていない場合、そのような検索は/etc/passwd
データベースを対象として行う。NSSが有効なシステムの場合、検索は、
nsswitch.conf
ファイル中で指定されたライブラリを通じて
行う。ライブラリを指定するそのファイル中のエントリは以下の通り:
passwd: files nis ldap shadow: files nis ldap group: files nis ldap
以下の例(実際に使われるようなものではないが)では、検索は、
/etc/passwd
と /etc/group
に対して
行われ、見つからなければ NISでチェックし、次にLDAPでチェックする。
ドメインセキュリティは、すべてのユーザーとグループアカウントを、中央の共有されている アカウントリポジトリに保存するメカニズムを提供する。中央のアカウントリポジトリは ドメイン(セキュリティ)コントローラー間で共有される。ドメインコントローラーとして振る舞う サーバーはドメインに対するセキュリティコンテキストに参加するすべてのマシンに、認証と 確認サービスを提供する。プライマリドメインコントローラー(PDC)はセキュリティアカウント データベースの完全性を管理するための責任を負うサーバーである。バックアップドメイン コントローラー(BDC)はドメインログオンと認証サービスのみを提供する。通常、BDCはPDCが 行うよりもより反応性がよいネットワークログオン要求を提供する。
Sambaがsecurity = domainモードで動作中の時、 Sambaサーバーはドメインセキュリティ信頼アカウント(マシンアカウント)を持ち、ドメイン コントローラーに対してすべての認証要求をパススルーする。別の言い方をすると、この設定は、 実際、それがドメインコントローラーとして振る舞う場合にも、Sambaサーバーをドメインメンバー サーバーにする。ドメインセキュリティに参加するすべてのマシンはセキュリティデータベース 中にマシンアカウントを持たなければならない。
ドメインセキュリティ環境ないで、セキュリティアーキテクチャの基盤は、ユーザーレベルの セキュリティを使う。ドメインメンバーであるマシンは開始時に認証を行わなければならない。 アカウントデータベース内にあるアカウントエントリの一部であるマシンアカウントは、 その名前がマシンのNetBIOS名であり、パスワードはランダムに生成され、ドメインコントローラー と他のマシンの両方に知られている。もしもマシンアカウントがセットアップ中に認証 されなければ、ユーザーは、それが認証できないため、そのマシンを使ってドメインにログオン できない。マシンアカウントはマシン信頼アカウントとして参照される。
ドメインメンバーの設定には以下の3つのパターンがある:
プライマリドメインコントローラー(PDC) - ドメインに1つのみ。
バックアップドメインコントローラー(BDC) - ドメインに複数配置可能。
ドメインメンバーサーバー(DMS) - ドメインに複数配置可能。
それぞれについて別の節で解説する。まずはじめに、もっとも関心のある基本的なDMSの設定について 説明する。
Sambaをドメインメンバーサーバーとする
この方法はsmb.conf
ファイル中に以下のパラメーターを必要とする:
security = domain |
workgroup = MIDEARTH |
この方法を動作させるために、SambaサーバーはMicrosoft Windows NTセキュリティドメイン にジョインする必要がある。これは以下の方法で行う:
Microsoft Windows NT ドメインコントローラー上で、サーバーマネージャを つかい、Sambaサーバーのマシンアカウントを追加する。
UNIX/Linuxシステム上で以下を実行する:
root#
net rpc join -U administrator%password
Samba-2.2.4とそれ以降の Samba 2.2.x 系列では、以下を実行することで、Windows NT4スタイル ドメインへの自動ジョインが可能である:
root#
smbpasswd -j
DOMAIN_NAME
-rPDC_NAME
\ -U Administrator%password
root#
net rpc join -U Administrator%
password
Samba-3ではDOMAIN_NAME
かPDC_NAME
を指定する必要はないので、smb.conf
ファイルの設定からこれをわかるようにする(訳注:訳があやしい)。
Windowsドメインコントローラーによってアカウントが認証される時に、UIDを割り当てるため、
このモードを使う認証は、おのおののユーザーに対する標準UNIXアカウントがあることを要求
する。このアカウントは、/etc/passwd
エントリ中で不正なシェルと
して設定するような方法で、Microsoft Windows以外のクライアントによってログオンする
ことをブロックすることができる。ユーザーアカウントに対して不正なシェルを割り当てる
最も良い方法は、シェルに/bin/false
を割り当てることである。
ドメインコントローラーは、利便性のために任意の場所に配置できる。BDCを配置する推奨は、 物理ネットワーク毎に配置し、もしもPDCがリモートネットワークセグメントにあるならば、 WINS(詳細はネットワークのブラウジングを参照)を 使うのが基本である。
Sambaサーバー上でWindowsユーザーにUIDを割り当てる別の方法は、 Winbindと Winbind: Use of Domain Accountsにある。
ドメインメンバーシップについてのより詳細な情報は Domain Membershipを参照のこと。
Samba-2.2とSamba-3の両方は、NT4スタイルのRPCベースのセキュリティを使って Active Directoryドメインに参加することが出来る。これは、ドメインがネイティブ モードで動作しているときに可能である。ネイティブモードのActive Directory は完全にNT4スタイルのドメインメンバーを許可する。これは世間一般の考えに反して である。
もしも、Active DirectoryをSamba-3と一緒に使っているとき、ネイティブなAD メンバーとしてジョインできる。なぜそれを望むか?NT互換の認証プロトコルの使用 をセキュリティポリが禁止するかもしれない。Windows2000とそれ以降のすべての マシンはKerberosを使用している。この場合、NT4スタイルのドメインとしての SambaはNT互換の認証データを引き続き要求する。ADメンバーモード中のSambaは、 Kerberosチケットを受け取ることが出来る。
Microsoft WindowsのActive Directoryサービス(ADS)を使うサイトは、以下の
用語の重要性に気づくべきである:
native mode
と mixed mode
の ADS操作。
The term
realm
という単語はKerberosベースのセキュリティアーキテクチャ
(Microsoft ADSによって使われるような)を説明するのに使われる。
realm = your.kerberos.REALM |
security = ADS |
以下のパラメーターを必要としても良い:
password server = your.kerberos.server |
この設定オプションの参考情報として、 ドメインメンバーシップと Samba ADS ドメインメンバーシップを参照してほしい。
サーバー席モードはドメインメンバーサーバーとして振る舞うのが出来ない場合に残されている ものである。この機能を使わないことを強く推奨する。サーバーセキュリティモードは 以下のような多数の欠点がある:
Microsoft Windows NT4/200xパスワードサーバー上でアカウントロックアウトの可能性。
Lack of assurance that the password server is the one specified.
リモートでプロファイルを格納するときに特に必要な、Winbindと一緒に動かない。
このモードはパスワードサーバーに対して接続をオープンにでき、また長期間それとオープンしたままにできる
突然リモートのパスワードサーバーが停止したときに、不正にSambaサーバーのセキュリティを壊す。
このモードでは、Sambaサーバーのために属するドメイン中のパスワードサーバーにセキュリティアカウントがない(訳注:訳が微妙)。
サーバーセキュリティモード中で、Sambaサーバーはクライアントに、ユーザーレベルセキュリティ であることを報告する。クライアントは次に以前に説明したようにsession setupを行う。 Sambaサーバーはユーザー名/パスワードペアをクライアントから得、クライアントから得た ユーザー名/パスワードペアと正確に同じものを送って password serverにログインしようとする。もしもサーバーが ユーザーレベルのセキュリティで動作していて、パスワードを受け入れるならば、Samba はクライアントからの接続を許可する。このパラメーターは password serverとしてSambaサーバーを、別のSMBサーバーを使う ことができるようになる。
どのセキュリティレベルであるかとクライアントに告げるとき、これらすべての開始時に もしも暗号化をサポートしているのであrばそのこともクライアントに告げる。もしも そうであれば、クライアントに対して乱数を使った暗号化キーを送信する。クライアント は暗号化形式ですべてのパスワードを送る。Sambaは既定値でこのタイプの暗号化を サポートする。
パラメーターsecurity = serverは user modeで動いていることをSambaがクライアントに報告する ことを意味するが、実際には別のユーザーモードサーバーに対してすべての認証要求を渡す。 これは、真の認証サーバーを差す追加のpassword server パラメーターを必要とする。真の認証サーバーは別のSambaサーバーでも、Windows NT サーバーでもよく、後者は標準で暗号化パスワードをサポートしている。
server security modeでSambaサーバーが動作しているとき、 パラメーターpassword serverをターゲットの認証サーバーの 正確なNetBIOSマシン名に設定することは必要である。Sambaは、ターゲットの認証 サーバーの選択は任意であり、ドメイン名から決定できないという理由で、NetBIOS 名前検索からこれを決定できない。本質的に、 サーバーセキュリティモードのSambaサーバーはワークグループ モードとして知られているものとして動作している。
Microsoft Windows NTを認証サーバーとして使う
この方法はsmb.conf
ファイル中に以下のパラメーターを追記することになる:
encrypt passwords = Yes |
security = server |
password server = "NetBIOS_name_of_a_DC" |
ユーザー名/パスワードペアが正しいかどうかを確認する2つの方法がある。 1つは提供された認証メッセージングプロセスの一部としてリプライ情報を使う ことであり、もう1つはエラーコードを使うことである。
このモードの設定の悪い点は、セキュリティの観点でSambaが偽のユーザー名と偽の パスワードをパスワードサーバーに送る可能性があることと、もしもリモートの サーバーが偽のユーザー名と偽のパスワードの認証拒否に失敗すると代替の認証か 承認作業が使われてしまうと言うことである。数回の認証の繰り返し後にサイト がパスワードロックを使う場合、これはユーザーをロックアウトしてしまう。
認証要求でのこのモードの使用はユーザーが標準UNIXアカウントがあることを必要と する。このアカウントは非SMB/CIFSクライアントからのログオンを防止するために ブロックすることが出来る。
Microsoft Windows クライアントはチャレンジ/レスポンス認証モデル(NTLMv1と NTLMv2として知られる)の一部としての暗号化パスワードか、単独か、あるいは 単純なパスワードベースの認証のための平文パスワードを使うことが出来る (訳注:aloneがよく分からない)。これはSMBプロトコルで実現され、パスワード は平文または暗号化されてネットワーク経由で渡されるが、同じ認証要求では 両方は使われない。
暗号化パスワードが使われるとき、以下の2つの方法でユーザーが入力した パスワードは暗号化される:
unicodeのパスワード文字列をMD4でハッシュ。 これはNTハッシュとして知られているものである。
パスワードは大文字化され、14バイトに短縮 される。この文字列に5バイトのNULL文字が追加され、"magic" な8バイト値に暗号化するために、2つの56ビットDESキー形式 に分割される。結果はLanManハッシュという16ビットの値である。
Microsoft Windows 95 サービスパック1より前とWindows NT バージョン3.xとバージョン 4.0のサービスパック3より前では、パスワード認証のどちらかのモードを使う。すべての それより後のMicrosoft Windowsバージョンはもはや既定値で平文パスワードをサポート しない。
Microsoft Windows クライアントは10分またはそれより長くアイドルな時にネットワーク マッピングを切断するという習性がある。切断した、マップされたドライブ接続を 使うためにユーザーが試みるとき、クライアントはキャッシュされたパスワードの コピーを使って再接続する。
Microsoftが既定値のパスワードモードを変更したとき、平文パスワードのキャッシュ サポートをやめた。これは、平文パスワードを使うためにレジストリパラメーターを修正 したときに、それは動くようになるが、もしもリモートの認証サーバーが暗号化パスワード をサポートしないときに、切断されたサービスのマッピングを試みるときに失敗する ことを意味する。そのようなクライアントで平文パスワードを再度有効にすることは 良い考えではないと確かに言える。
以下のパラメーターは、平文テキストでの認証を使うときに、Windows 9x/Meクライアントが 大文字化したユーザー名とパスワードをSMBサーバーに送る前に問題になる時に使うことが できるものである:
既定値では、Sambaはローカルのシステムアカウントデータベース中でユーザー名を検索する前に ユーザー名を小文字に変更する。これは、UNIXユーザー名が慣習的に小文字のみで構成されている ことによるためであり、username-levelパラメーターは滅多に必要と さない。
しかしながら、UNIXシステム上のパスワードはしばしば大文字小文字を混ぜた文字で構成され ている。これは、平文認証を使ってSambaサーバーに接続しようとするWindows 9x/Meクライアント 上でのユーザーのために、password levelが、パスワードに現れること が出来る大文字の最大数を設定しなければならないことを意味する。 もしもサーバーのOSが伝統的なDESバージョンを使うcrypt()を使うならば、 password levelを8に設定することは、結果としてWindowsユーザー にとって、大文字小文字を無視したパスワードとして見える。これはまた、一致するまで (あるいはすべての組み合わせが失敗するまで)1つ1つ、Sambaがパスワード文字列の組み合わせ を試みるために、より長いログイン時間がかかるという結果となる。
最も適用するのによいオプションは、Sambaが使われている所はどこでも、暗号化パスワード をサポートすることを有効にすることである。平文パスワードを使うためにレジストリを 変更する試みは、結局はユーザーの苦情と不便を導くことになるだろう。
我々はいつでも間違いを犯す。正しい場所で正しい時間と同じくらいの長さで間違いを犯す のは問題ない(訳注:意味がよく取れない)。製品版での重要な障害は重要視されるが、 ラボでの開発バージョンにおいてのバグは期待されるものである。
Sambaメーリングリスト上の議論の題名となる共通の誤解と間違いを見てみよう。 その多くは、Samba実装を試みる前にあなたの宿題としてその多くが回避可能である。 そのいくつかは、英語を母国語としない人にとって、潜在的に曖昧で、とても紛らわしい 多くのフレーズを持つ英文の誤解釈の結果である。
ある人たちにとって、Sambaのセキュリティモードの性質は明白であるが、 それでも完全に間違っている(訳注:意味取れない)。 security = serverはSambaがサーバーとして 動くと言うことを意味していることを仮定している。が、違う。この設定は、 Sambaが、別のSmBサーバーがユーザー認証サーバーだけの提供元として使うことを 試みることを意味している。
Sambaはセキュリティモードが選択されたとしてもサーバーである。Sambaが ドメインセキュリティコンテキストの外で使われた場合、既定値にセキュリティ モードをしておくのが最適である。Samba-3の既定値では、ユーザーモードの セキュリティを使う。
smb.conf
パラメーター security = domainは
実際にSambaをドメインコントローラーとして振る舞わさせるのではない。この設定は
Sambaがドメインメンバーになることを期待することを意味する。より詳細については
PDCとしてのSambaを参照のこと。
想像してみよう!So many others do. But whatever you do, security = userはSambaをドメインメンバー として振る舞わせることを考えてはいけない。保証期限が切れる前に製造者の マニュアルを読みなさい。より詳細については、 ドメインメンバーシップを参照のこと。
“ なぜ、server_validate()は単に、パスワードサーバーに対する接続を再接続しないで あきらめるのか?私はSMBプロトコルに詳しくはないが、たぶん、クラスターサーバー プロセスはそのクライアントワークステーションの方に、パスワードサーバーから 渡されたセッションキーを渡し、それはクライアントから送信されたパスワード ハッシュが、セッションキーが異なるそのあとの接続で動作しないことを意味する。 (訳注:ちょっと不安)そのため、server_validate()は中断しなければならない。 ”
本当に。それは、なぜ security = server が全くひどいハックである理由である。認証をパススルーすることが分かっている、 security = serverモードである、 security = domainを使ってほしい。
“ DOMAINに入ろうとしたとき、イベントログに tried credentials DOMAIN/username; effective credentials SERVER/usernameが表示された。 ”
通常これはSambaサーバーがドメインコントローラーとして設定される前にユーザーかマシン アカウントが作成されたことによるものである。サーバーがドメインコントローラーになる まえに作成されたアカウントは、ローカルのアカウントであり、 SERVERドメイン中のメンバーとして見えるものとしてに認証され、Windows 2000とそれ 以降の中のローカルユーザーアカウントとほとんど同じである。Sambaサーバーがドメイン コントローラーになったとに作成されたアカウントは、 ドメイン アカウントであり、DOMAINメンバーのメンバーとして認証される。
これは、pdbedit -L -v username
コマンドをを発行することによって
確かめられる。もしも、これがDOMAINという結果を出したならば、アカウントはドメイン
アカウントであり、もしもSERVERであれば、そのアカウントはローカルアカウントである。
これを解決する最も簡単な方法は、アカウントを削除し再作成することである。しかしながら、
この方法は、ユーザープロファイルの確率に問題を引き起こすかもしれない。
pdbedit -u username -I DOMAIN
コマンドを使うことも出来る。
ドメインに一致するためにユーザーSIDとプライマリグループSIDを変更する必要がある
かもしれない。
Table of Contents
Microsoft Windows のネットワークの世界に考えられないような誤解をしている人が たくさんいる。それは私たちが支援を提供できる機会が増えるということですからそれはそれでいいのだが、 この分野で本当にヘルプを必要とする人は、まず、既に一般向けに出されている情報に親しむことを 推奨する。
ある程度の基本を理解・修得されてからこの章を読み進めることを推奨する。Microsoft Windowsネットワーク では、誤った設定の影響がはっきりと現れる。Microsoft Windows ネットワークのユーザーから、 ネットワーク設定の誤りに起因すると思われる細かなトラブルにしつこく悩まされるという 苦情が出ることがよくある。ところが、多くの人々にとって Microsoft Windowsネットワークの 世界というのはドメインコントローラーを知るところから始まり、それはネットワーク操作の障害を 魔法のように、すべて解決してくれそうに思えるてくるものである。
ドメインの例の図解は典型的な、Microsoft Windows ネットワーク ドメインセキュリティネットワーク環境を図示している。 ワークステーションA、BとCは多くの物理的なMicrosoft Windowsネットワーククライアント を代表していると考えられたい。
Sambaメーリングリストから、よくあるネットワークに関する問題の多くを容易に特定できる。 もしも以下の話題についてよく分からないのであれば、それについて取り扱っている、 このHOWTO文書の節を読むことを強く勧める。以下は、最も一般的なMicrosoft Windows ネットワークの問題である:
基本的なTCP/IPの設定
NetBIOS名の解決方法
認証の設定
ユーザーとグループの設定
UNIX/Linux上での基本的なファイルとディレクトリのアクセス制御
ネットワーク環境中でMicrosoft Windowsクライアントがどのようにやりとりをするかの理解
がっくりする必要はない。Microsoft Windowsのネットワーク機能は、一見、大変シンプルで 誰でもできそうに見える。実際には、適切な研修と準備をしないで Microsoft Windows ネットワーク を設定するのは、あまりよい考えとは言えない。とはいえ、なかなか払拭できない思い込みをちょっと 脇にどけることにしよう。ミスを犯すのもいいことです!時と場合によっては 失敗も教訓となる。しかし、生産性のロスを招き、組織に不可避の財政負担を強いるようなミスを 犯してもよいわけではない。
それでは、ミスを犯してもよい場所とはどこであろうか? それは実害のない場所である。ミスを犯すなら、 テストネットワーク上で、ユーザーから遠く離れた場所で、他の人に苦痛を与えない状況でやってほしい。
Microsoftドメインセキュリティの最も重要な利便性は何か?
要するに、シングルサインオン、あるいは短く言えばSSO である。これは多くの人にとって、Microsoft Windows NT 以後のネットワーキング における聖杯である。SSOは、ユーザーのユーザーアカウントが存在するドメインの メンバーであるワークステーション(あるいは、アクセスするドメインとの間に適切な 信頼関係があるドメインに属するワークステーション)のいずれからも、ネットワーク にログオンできるという優れた設計を可能にする。ユーザーは、自分のホームの(個人の) ワークステーションの前に座っているかのように、ネットワークにログオンでき、 リソース(共有、ファイル、プリンター)にアクセスできる。これはドメインセキュリティ プロトコルの一つの特長である。
Samba PDCを実装するサイトは、ドメインセキュリティの利便性を享受できる。ドメイン は、固有のネットワーク・セキュリティ識別子(SID)を提供する。ドメインユーザーと グループセキュリティの識別子は、ネットワーク SID に、アカウント毎に一意の 相対識別子(RID)を付け足したものである。ユーザーとグループのSID(ネットワークSID +RID)は、ネットワークリソースに付けられるアクセス制御リスト(ACL)を作成するのに 使用され、組織内のアクセス制御を可能にする。UNIXシステムは、ローカル セキュリティ識別子のみ認識する。
SIDはセキュリティコンテキストを表す。例をあげると、おのおののWindows マシンは固有のSIDを持つローカルマシンのセキュリティコンテキストでの ローカルアカウントを持つ。すべてのドメイン(NT4、ADS、Samba)は ドメインSIDによって定義されるセキュリティドメインセキュリティコン テキストで存在するアカウントを含む。
ドメインメンバーサーバーはドメインSIDとは異なるSIDを持つ。ドメインメンバー サーバーはすべてのドメインユーザーをローカルユーザーとして見なすように 設定できる。SIDは持続的である。標準的なドメインのユーザーSIDは以下の ようなものである:
S-1-5-21-726309263-4128913605-1168186429
すべてのアカウント(ユーザー、グループ、マシン、信頼関係など)はRIDが割り当てられる。
これは、アカウントが作成された時に自動的に行われる。UNIX OSはユーザーとグループ
識別子に別々の名前空間を使う(UIDとGID)が、Windowsは同じ名前空間からRIDを
割り当てる。WindowsユーザーとWindowsグループは同じRIDを持てない。ちょうどUNIX
ユーザーroot
がUID=0であるように、Windows Administrator
は、よく知られたRID=500を持つ。RIDはWindowsドメインRIDに連結され、そのため、
上記のSIDを持つドメインのAdministratorアカウントは下記のユーザーSIDを持つ。
S-1-5-21-726309263-4128913605-1168186429-500
Windowsネットワーク領域中での残りのすべてのアカウントは全体で一意なセキュリティ 識別子を持つ。
Microsoft Windows ドメインセキュリティ環境でのネットワーククライアントは提供される 高度な機能にアクセス出来るためには、ドメインメンバーでなければならない。ドメイン メンバーシップはワークグループ名をドメイン名に設定するだけではない。ワーク ステーションに対する(マシンアカウントと呼ばれる)ドメイン信頼アカウントの作成 が必要である。より詳細については ドメインメンバーシップを参照のこと。
以下の機能はSamba-3リリースで新規に追加された:
Samba-3はユーザー、グループとマシンアカウントが格納される時に使われる バックエンドの選択を行う事をサポートしている。複数のパスワードバックエンド を、付加的なデータセット、あるいはフェールオーバーデータセットのどちらでも、 組み合わせて使うことが出来る(訳注:今は使えない)。
LDAP passdbバックエンドは、拡張性と高いレベルでの信頼性を 提供するという理由で、とても価値のある、アカウントバックエンドが 分散かつ複製が出来るメリットを享受できる。
Windows NT4のドメイン信頼関係である。Samba-3はワークステーションと サーバー(マシン)信頼アカウントをサポートする。これは、ネットワークの スケーラビリティと相互運用性をさらに支援する、NT4スタイルのドメイン 間信頼アカウントをサポートする。
NetBIOS over TCP/IPなしの操作は、むしろraw SMB over TCP/IPを使うことである。注意: これはMicrosoft active directoryドメインメンバーサーバーとして操作する時にのみ 実行可能である。Sambaドメインコントローラーとして動作する時、NetBIOSの使用は、 ネットワークブラウジングのサポートを提供するために必要である。
Samba-3はNetBIOSネームサービス(WINS)、NetBIOS ever TCP/IP(TCPポート139)、 SMB over TCP(TCP port 445)セッションサービスとMicrosoft互換のONC DCE RPCサービス(TCPポート135)を提供する。
ドメインにユーザーマネージャ経由でユーザーとグループを管理する機能。
これは、Windows 9x/MeではNexus.exe
を使い、
Windows NT4/200x/XPプラットフォームではSRVTOOLS.EXEを使って任意の
Microsoft Windows クライアントで行える(訳注:Windows Vista/7では
使えない)。
Unicodeの完全な実装。これは、ロケール間での国際化サポートを容易にする。 また、Unicode を完全にサポートしなければならないという理由でSamba-2.2.x がサポートできなかったプロトコルの活用の道を開く。
以下の機能はSamba-3では提供されていない:
NT4ドメインコントローラー間でのSAMの複製(すなわちSamba PDCとWindows NT BDCまたはその逆)。 これは、Sambaが、PDCがMicrosoftベースのWindows NT PDCである時にBDCと して動作出来ないことを意味する。Samba-3はWindows PDCとBDCでのアカウント データの複製に参加できない。
Windows 2000 Active Directoryドメインコントローラーとして動作する (すなわち、KerberosとActive Directory)。実際の所、Samba-3は 現時点では若干の、実験的なActive Directory ドメイン制御の機能を 有している。Active Directoryドメイン制御は次世代のSambaリリース である、Samba-4で現在開発中の機能である。現時点ではSamba-3ライフ サイクル中でActive Directoryドメイン制御を有効にする計画はない。
Windows 200x/XPのMicrosoft管理コンソール(MMC)はSamba-3サーバーの管理に は使えない。この目的にはMicrosoft Windows NT4ドメインサーバーマネージャと Microsoft Windows NT4ドメインユーザーマネージャのみが使える。両者は この後説明するSVRTOOLS.EXEパッケージ中の一部である。
この章の中で説明されている理由により、Windows 9x/Me/XP Homeクライアントは ドメインの真のメンバーになれない。Windows9x/Meスタイルのネットワーク(ドメイン) ログオンプロトコルはNT4/Windows 200xスタイルのドメインログオンとは完全に異なり、 しばらくの間公式にサポートされてきた。これらのクライアントはおおよそ Samba-1.9.15シリーズからサポートされた旧LanManネットワークログイン機能を使う。
Samba-3ではWindows NT グループとUNIXグループ間でのグループマッピングを実装 している(これは、限られたスペースでは説明できないくらい非常に複雑で ある)。これについての詳細については グループマッピング:Microsoft WindowsとUNIX を参照のこと。
Samba-3はMicrosoft Windows NT4 PDCまたはWindows200x Active Directory と同様に、適切なバックエンドデータベースにユーザーとマシン 信頼アカウント情報を格納することを必要とする。これについては、 Microsoft Windows ワークステーション/サーバー マシン信頼アカウント を参照のこと。Samba-3では複数のバックエンドが用意されている。 完全なアカウントデータベースバックエンドについての解説は アカウント情報データベースを参照のこと。
ネットワーク管理者が、Windows NT4とactive directoryネットワークの利点に ついて説明を求められるとき、しばしば言及するのが、シングルサインオン (SSO)を実装しているということである。多くの会社がSSOを実装している。 シングルサインオンソリューション実装のモードは、一般的に、ネットワーク 業務における重要な要因であり、Windowsネットワークに関してとても重要で ある。会社には多くの種類の情報システムがあり、それぞれはユーザー認証と認可 (訳注:authentication and validation)を要求し、そのため、一般的 ではないが、ユーザーは10以上のログインIDとパスワードを記憶する必要が あるかもしれない。この問題は、おのおののシステムのパスワードが 一定期間で更新が必定で、パスワードの複雑さとパスワード履歴が 適用されるときには特に顕著となる。
非常に数多くの情報システムに対するアクセス権限(ユーザー名/パスワードペア) を扱うユーザーの問題に対する回答がSSOであるという認識を包括的に 持っている。多くの巧妙な案が、ユーザーフレンドリーなSSOのソリューション を提供可能にするために考案された。問題は、この導入がうまく終わって いない場合、サイトは複雑さによるたくさんの費用と管理上のオーバーヘッド が起きるかもしれないということである。簡単に言って、多くのSSOソリュー ションは管理上の悪夢である。
SSOを使うことですべてのユーザーアカウント情報を集中管理できる。 環境の複雑さと、SSOを導入したシステムの稼働期間に依存して、 新しいアイデンティティ管理とユーザー認証システムを受け入れること は可能ではないかもしれない。多くのSSOソリューションは、 ユーザーのための認証を処理する新しい上位の構造から成り立つ レガシーシステムを改良する。これは、SSOの追加は全体的な情報 システムの複雑さを増大することを意味する。理想的には、SSOの 導入は複雑さの低減と管理オーバーヘッドの削減をすべきである。
たくさんのネットワーク管理の最初のゴールは、しばしば集中管理した アイデンティティ管理システムを作り、使うことである。これは、 そのような集中化したシステムは、すべての情報システムによって 使うことが出来る単一の認証基盤を使うことをしばしば仮定している。 Microsoft Windows NT4セキュリティドメインアーキテクチャとMicrosoft Active Directoryサービスは、そのようなシステムに対しての理想的な 基盤としてしばしば提供される。ユーザーの認証とアクセス制御のために Microsoft(NT4ドメインかadsサービス)を使うことが出来る単一の 認証基盤を使う、そのような集中化したシステムがしばしば仮定される。 単一の集中化した認証サービスのすばらしい幻想は一般的に、現実を 理解するときに一般的に壊れている。レガシーシステムを使うときの問題 は、その導入がリエンジニアリングの観点から、過度に侵略的になるか、 アプリケーションソフトが、設計されて実装されたユーザー認証の特定の 要素に依存して組み込まれているという理由により、認証とアクセス制御 を具体化する能力がしばしばないということである。
これまでの10年間、産業が、レガシー名情報テクノロジーシステムの 制限の鍵となる点を回避するために作られた、いろいろな方法が開発 されてきた。しばしば使われるその1つの方法はメタディレクトリを 使うことである。メタディレクトリには、それぞれのシステムに固有な 形式で、すべての異なる情報システムのためにユーザー認証情報を保存 する。単一のユーザー認証情報を使うすべてのシステムのために、新しい 基盤がユーザーアクセスを可能にさせることが提供されるシステムの 迷宮の中で、ユーザー権限と権利(rights and privileges)を管理する ための厳格に実施されるワークフロープロトコルに、管理手続き の巧妙なセットが結合される。
Organization for the Advancement of Structured Information Standards (OASIS) は、認証情報の通信のための構造化情報であるSecurity Assertion Markup Language (SAML) を開発している。SAMLを配置するための全体的な技術と手法の包括的名称(訳注:umbrella name)は Federated Identity Management (FIM)と呼ばれる。FIMはそれぞれのユーザーを認証 するための異なった情報システムの複雑な迷宮中で、かつおのおのが提供するサービス の安全なアクセスを請け負うために、おのおののシステムに依存する。
SAML文書はWebサービスのために必要なコンピュータ間通信のための Simple Object Access Protocol (SOAP)メッセージ中に包むことが出来る。 あるいは、ライブサービスを共有する集合化したWebサービス間で渡される かもしれない。リバティ・アライアンスは、SAML1.1をアプリケーション フレームワークとして適用した、連携型アイデンティティ標準 (訳注:federated-identity standards)を普及させるために作られた コンソーシアム(訳注:industry group)である。MicrosoftとIBMは WS-Securityと呼ばれる別の方式を提案していた。ある人は、競合して いる技術と手法がSAML 2.0標準が世に出るときにまとまるのではないか と信じていた。現在ではごく少数のWebアクセス管理製品のみがSAMLを サポートしているが、技術の実装は、アプリケーション統合のための カスタマイズとユーザーインタフェースの開発のために、主に必要と される。要するに、それがなぜFIMが大木つて成長している産業である かの理由である。
この本の向こうの範囲の大きな絵を無視し、集中したシステムへのすべての ユーザーとグループのマイグレーション管理は、正しい方向への第一歩である。 Microsoft Active Directoryサービス(ADS)やその他のプロプライエティな ものか、general security service application programming interface (GSSAPI)サービスによって定義されているプロトコルを使う数々の認証 メカニズム(kerberosのような)の柔軟な組み合わせができる情報アクセス (LDAPのような)のための、標準プロトコルを提供するオープンソースシステム のような、ディレクトリ中にアイデンティティ管理システムデータを位置づける のは、相互運用性のための基本である。
ますます多くの会社がLDAPシステムを使うことを許可するための異なったレガシー プラットフォームのために認証エージェントを提供する。OpenLDAPの使用で、 LDAP標準のオープンソース実装が支配的である。実際、LDAPとMicrosoft ADSを使うためにSambaで提供することは、Sambaが、高度な拡張性と Sambaは、組織のネットワーク技術に届くように前進することを意味する。
Microsoft ADSは、集中化した認証基盤を提供するために拡張できる、
制限付きの完全に商用なサービスを提供する。SambaとLDAPは、集中化した
認証基盤の拡張のための同様な機会を提供するが、実際、Sambaチームは、
LDAPあるいは他のものを使って、認証サービスの拡張の導入中で、
、持続可能な選択とFIMマーケットプレイス中での競合をより多く作成する、
ntlm_auth
ユーティリティのような完全なツールを
SQUID(OSSのプロキシサーバー)のようなアプリケーションのために
先を見越している。
もしも、プライマリドメインコントロールが大きなサイトに適合した拡張性 があれば、LDAPを使うことが出来るに違いない。それを使うためのすばやい OpenLDAPとSambaの設定は、ディレクトリの時代が始まったことの十分な 証明である。Samba-3はLDAPの使用を要求しないが、分散可能なユーザーと グループのイデンティティ情報のメカニズムのための要求は、それを不可避の 選択としている。
この時点で、SambaベースのBDCの使用は、LDAPアクセスありの使用を必要と する。最も一般的な、Sambaサイトによって使われるLDAP実装はOpenLDAP である。標準準拠の任意のLDAPサーバーを使うことも可能である。それらは、 IBM、CA、Novell(e-Directory)とその他で知られている。
長年の間に、ドメイン管理に関する一般の理解はほとんど神話の世界になってきた。 ドメイン制御についての基本を概観する前に、 ドメインコントローラーの3つのタイプについて説明する。
NT4スタイルプライマリドメインコントローラー
NT4スタイルバックアップドメインコントローラー
ADSドメインコントローラー
プライマリドメインコントローラーあるいはPDCはMicrosoft Windows NTで重要な役割を演じる。Windows 200xドメインアーキテクチャ中では この役割はドメインコントローラーが担う。Microsoft Windowsネットワークにおける ドメインコントローラーの役割は、ドメインコントローラーがネットワークの中で 最も強力で最も能力のあるマシンでなければならないことを示す、ということになって いる。ところが、おかしなことを言うと思われるかも知れないが、ネットワークの 全体的な性能を高めるためには、インフラストラクチャー全体がバランスのとれた ものでなければならない。ドメインコントローラーよりもスタンドアロン (ドメインメンバー)サーバーに投資する方が賢明である。
Microsoft Windows NT4スタイルドメインの場合、新しいドメイン制御データベースを 初期化するのはPDCである。これにより、Security Account Manager (SAM)と呼ばれる Windowsレジストリの一部分が形成される。これは、NT4スタイルのドメインユーザーの認証と BDCのドメイン認証データベースとの同期で鍵となる役割を果たす。
Microsoft Windows 200xサーバーベースのActive Directoryドメインでは、一つのドメイン コントローラーが、複数のドメイン・コントローラーの階層関係を初期化し、一つ一つの コントローラーが管理権限を代行する領域を与えられる。 マスタードメインコントローラーは下位のいずれかのドメインコントローラーの 決定を上書きする能力を持っているが、下位のコントローラーはその下位の コントローラーのみ制御する。Samba-3では、この機能はLDAPベースのユーザーとマシン アカウントバックエンドを使うことで実現できる。
Samba-3では、新たにNT4スタイルのSAMデータベース(レジストリファイルの1つ)と 同じタイプのデータを保持するバックエンドデータベースを使う機能が入った。 [1]
バックアップドメインコントローラーまたはBDCはネットワーク 認証リクエストの処理に重要な役割を演じる。BDCはPDCに優先してログオン要求に答える ようになっている。BDCとPDCの両方があるネットワークセグメント上では、 ネットワークログオン要求はおおむねBDCが処理する。PDCはBDCが高負荷 (ロードアベレージが大きい)ときにログオン要求に応える。ユーザーがWindows ドメインメンバークライアントにログオンした時、ワークステーションは最も近い ネットワークログオンサーバーを探すために、ネットワークに問い合わせを 行う。WINSサーバーが使われている時は、WINSサーバーへの問い合わせ で行われる。もしもネットログオンサーバーがWINS問い合わせでは見つからないか、 WINSサーバーがない場合、ワークステーションはUDPブロードキャストプロトコル 上でmailslotブロードキャスト経由でNetBIOS名前検索を実行する。これは、 Windowsクライアントが使うことが出来るネットログオンサーバーがたくさんの 変数によって影響され、それゆえ、PDCまたはBDCが特定のログオン認証要求 を処理する単純な決定要素はない。
Windows NT4 BDCはPDCに昇格することが出来る。BDCがPDCに昇格する時にPDC がオンラインならば、以前のPDCは自動的にBDCに降格する。Samba-3では これは自動的には行われない。PDCとBDCは手動で設定し、その他適切な 変更を行う必要がある。
Microsoft Windows NT4では、インストール時に、サーバーのマシンタイプが 何になるかを決める。BDCからPDCへの昇格やその逆も 可能である。Windows NT4ドメインコントローラーからドメインメンバーサーバー かスタンドアロンサーバーへの変換のためにMicrosoftが提供している唯一の 手法は、再インストールである。インストール時に提供されている選択肢 は以下の通り:
プライマリドメインコントローラー ドメインSAMを生成するサーバー。
バックアップドメインコントローラー ドメインSAMのコピーを受け取るサーバー。
ドメインメンバーサーバー ドメインSAMのコピーを持たない。すべてのアクセス制御についてドメインコントローラーから認証を受け取るサーバー。
スタンドアロンサーバー SAM同期を行わず、固有の認証データベースを持ち、ドメインセキュリティでは何の役割も担わないサーバー。
Algin Technology LLC はWindows NT4スタンドアロンサーバーをPDCまたはBDCに昇格 することとその逆ができるが可能な商用ツールを提供している。さらなる情報は AlginのWebサイトを参照 のこと。
Samba-3サーバーはsmb.conf
ファイルに簡単な変更をすることで、ドメイン
コントローラーへ、あるいはドメインコントローラーから容易に変換できる。
Samba-3はWindows200xサーバーのActive Directoryドメインでのネイティブ
なメンバーとして完全に振る舞える。
完全な図を提供するために、Microsoft Windows 2000 ドメイン制御の設定は サーバーがインストールされた後に行われる。ドメインメンバーサーバーへの変換、 あるいはドメイン制御からの変換を行うための手順と、Active Directory サービスのサポートのインストール、あるいはActive Directoryから抜ける ための方法については、Microsoftの資料を参照してほしい。
Samba-3での新機能として、SAM複製コンポーネントを除く、Microsoft Windows NT4スタイルのドメインコントローラー機能の実装が上げられる。しかし、Samba-3 はMicrosoft Windows 200xドメイン制御プロトコルについてもサポートすることも 注目してほしい。
現時点で、Samba-3はネイティブADSモード中でのドメインコントローラー として機能することが出来るように見えるが、これは限定的で実験的なもの でしかない。この機能はSambaチームがそれに対する公式のサポートを提供する まで使うべきでない。その時期になれば、すべての設定上・管理上の要件を 正当に反映するためにドキュメント類は改訂されるだろう。SambaはWindows 2000/XP環境中 ではNT4スタイルのドメインコントローラーとして振る舞うことが出来る。しかし、 以下のように一定の短所(訳注:未実装の機能)がある:
マシンポリシーファイルがない
グループポリシーオブジェクトがない。
同期して実行されるActive Directoryログオンスクリプトがない。
ユーザーとマシンを管理するためのActive directory管理ツールが使えない。
レジストリの変更でメインのレジストリに恒久的な変更が残るが、Active Directoryを使うときには、結果が残らない。
Active Directoryなしでは、特定のアプリケーションを特定のユーザーとグループにエクスポートできない。
Microsoft Windows のマシンが、お互いに他のサーバーやドメインコントローラー とやりとりするのには2つの方法がある:そのうちの1つは、一般的に ワークグループメンバーとして呼ばれている スタンドアロンシステムであり、もう1つは、 一般的にドメインメンバーと呼ばれている、 セキュリティシステム中で全面的に参加するものである。
ワークグループのメンバーであるために、特別な設定は必要ないということに注意してほ しい。ただ、ネットワーク設定に、ワークグループのエントリーについて共通に使う 単一の名前を持つようにマシンを設定するだけである。この時WORKGROUPという名前を使 うのが一般的である。この設定モードでは、マシン信頼アカウントはなく、メンバーシッ プの概念は、すべてのマシンがネットワーク環境の中で、論理的に一緒のグループに まとめられているという以上のものではない。繰り返すが、明確言うと、 ワークグループモードは、セキュリティの確保されたマシンアカウントを含まない。
ドメインメンバーのマシンは、ドメインアカウントデータベース中にマシン信頼 アカウントを持つ。ドメインメンバーシップを有効にするには、おのおののマシン上で 以下の特別な手続きが必要である。この手続きは、ローカルマシンのAdministrator アカウントによってのみ行うことが出来、これにより、ドメインマシンアカウント(もしも 存在しなければ)を作成し、そのアカウントを初期化する。クライアントが 最初にドメインにログオンすると、それがマシンアカウントのパスワード変更処理 のトリガとなり自動的に起動される。
Sambaがドメインコントローラーとして設定されるとき、セキュアなネットワーク操作は Microsoft Windows NT4/200x/XP Professionalクライアントがすべてドメインメンバー として設定されることを要求する。もしもマシンがドメインのメンバーでなければ、 それはワークグループ(スタンドアロン)マシンとして操作される。ドメインメンバーシップ に関係する情報は ドメインメンバーシップ を参照してほしい。
以下はMicrosoft Windows NT4/200x/XPクライアントのための、Microsoft Windows NT4スタイルとしてSamba-3を設定するために必要な手順である:
基本的なTCP/IPとMicrosoft Windows ネットワークの設定。
正しいサーバーの役割の指定(security = user)。
一貫性のある名前解決の設定。[2]
Windows NT4/200x/XP Professionalクライアントのためのドメインログオン。
移動プロファイルの設定か、明示的にローカルプロファイルを強制使用する設定。
network/systemポリシーの設定。
ドメインユーザーアカウントの追加と管理。
Microsoft Windows NT4/2000 ProfessionalとWindows XP Professionalクライアントマシンがドメインメンバーになるような設定。
以下の準備はMicrosoft 9x/Meクライアントに機能を提供するために必要な手順である:
基本的なTCP/IPとMicrosoft Windowsネットワークの設定。
正しいサーバーの役割の指定(security = user)。
ネットワークログイン設定(Windows 9x/Me/XP Homeは技術的にドメインメンバーに なれないため、ドメインログオンにおけるセキュリティ面には実際には参加しない)。
移動プロファイルの設定
システムポリシーの取り扱いの設定。
“Microsoft Windowsネットワーク用のクライアント”ネットワークドライバーのインストール とドメインにログオンするための設定。
もしもすべてのクライアント共有アクセスがドメインユーザー/グループ識別子に従って制御され ることが望ましいならば、Windows 9x/Meクライアントをユーザーレベルのセキュリティに設定 。
ドメインユーザーアカウントの追加と管理。
移動プロファイルとシステム/ネットワークポリシーは、高度なネットワーク管理の話題で、 このドキュメントの デスクトッププロファイル管理と システムとアカウントポリシーで触れられている。 しかしながら、それらはWindows NT ネットワーク のコンセプトに関連するので、必ずしもSamba PDCに固有の説明ではない。
ドメインコントローラーはSMB/CIFSサーバーであって以下を行う:
それらを提供するためにSambaを設定することはむしろ容易である。おのおののSamba
ドメインコントローラーは Sambaがdomain logons機能(smb.conf
ファイル中のパラメーターから取って)と呼ぶNETLOGONサービスを提供しなければな
らない。さらに、Samba-3ドメイン中の1つのサーバーはドメインマスターブラウザーとして
それ自身を公告しなければならない。[3]これにより、与えられた
ドメインまたはワークグループにDMB識別されるようなドメイン固有のNetBIOS名
をPDCが取得することになる。ブロードキャストで分離されたサブネットの、同じドメイン
またはワークグループ上の複数のローカルマスターブラウザー(LMB)は、WAN全体の
ブラウズリストの完全なコピーのために問い合わせを行う。
ブラウザークライアントは次にそれらのLMBに接続し、ブロードキャストで分離
されたサブネットのためのリストだけではなく、ドメイン全体のブラウズリストを受け取る。
Samba PDCを作成するための作業の第一歩はsmb.conf
中で必要なパラメーターの
理解である。PDCとして機能するためのsmb.conf
の例は以下の
PDC用のsmb.confの例である。
Example 4.1. PDC用のsmb.confの例
上記の例中で示される基本的なオプションの説明は以下の通り:
ここにすべてのユーザーとグループアカウント情報が含まれている。PDCで使える値は: smbpasswd, tdbsamとldapsamである。“guest” エントリは既定値のアカウントを提供し、それは既定値で含まれている;明示的に 追加する必要はない。
BDCを使う場合、passdb backendを配信するために論理的な唯一の選択肢は LDAPを使うことである。tdbsamとsmbpasswdファイルは効果的に配信できないため、それを 使うべきではない。
パラメーターos level, preferred master, domain master, security, encrypt passwordsとdomain logonsはドメイン 管理とネットワークログオンのサポートを確実にするために中心的な役割を演じる。
os levelは32以上にし、user モードセキュリティ、Microsoft互換の暗号化パスワードサポート、 ネットワークログオンサービス(ドメインログオン)を提供するように 設定しなければ ならない。暗号化パスワードは有効にしなければならない。 この設定についての詳細は、 アカウント情報データベースを参照のこと。
パラメーターlogon path, logon home, logon driveとlogon script は環境サポートの設定で、クライアントログオン操作機能を支援し、ネットワーク管理の 間接費用を軽減するための、自動コントロール機能の提供するものである。 それらのパラメーターに関しては、マニュアルページの情報を参照してほしい。
NETLOGON共有はドメインログオンとドメインメンバーシップサポートで中心的な役割を演じる。 この共有はすべてのMicrosoftドメインコントローラー上で提供される。これは、ログオン処理のために 必要となるかもしれない他の共通ツールを見つけるのと同じように、ログオンスクリプト の提供と、グループポリシーファイル(NTConfig.POL)の格納のために使われる。これは、 ドメインコントローラー上で不可欠な共有である。
この共有はユーザーのデスクトッププロファイルを格納するために使われる。各ユーザー はディレクトリのrootにこの共有を持たねばならない。このディレクトリはユーザーが 書き込み可能で、グローバルに読み込み可能でなければならない。Samba-3は “fake_permissions”と呼ばれる、この共有上にインストール可能な VFSモジュールを用意している。これはSambaの管理者が、全員に対してこのディレクトリを 読み込みのみにすることを許可する。もちろん、これはプロファイルが適した形で作成された 後に行ってこそ有用である。
Samba-3はActive Directoryサーバーとしては機能しない。真のActive Directoryの PDCとして機能することもできない。いくつかのActive Directoryドメインコントローラーの機能用の プロトコルが実験的なものとして部分的に実装されてはいる。しかし、Samba-3がそれらのプロ トコルをサポートするとは思わないでほしい。現在または将来にわたって、そのような 任意の機能に依存しないでほしい。Sambaチームは将来これらの機能を取り除いたり 機能を変更するかもしれない。このことをここに言及するのは、これらの秘密の機能を すでに発見し、この機能が完成されるのはいつかという質問を寄せられた方々のためである。 その答えは、「出来るかもしれないし出来ないかもしれない!」である。
たしかに、Samba-3はMicrosoft Windows NT4スタイルのドメインコントローラーが持つ 大部分の機能を提供するように設計されている。Samba-3にはWindows NT4の全ての 機能があるわけではないが、一方Windows NT4 ドメインコントローラーにはない 多くのの特徴を持っている。要するに、Samba-3はNT4でもWindows Server 200xでもない。 もちろんActive Directoryサーバーでもない。この言い方で全ての人に簡単にシンプルに 理解していただけると期待している。
ネットワークとドメインのログオンについて、ここで言及するのは、ドメインコントローラー が提供する本質的な機能の欠かせない部分だからである。
すべてのドメインコントローラーはネットログオンサービスを動かさなければ ならない(Samba中でのドメインログオン)。 1つのドメインコントローラーが domain master = Yes(PDC)と設定 しなければならない;すべてのBDCではパラメーターを domain master = Noと設定しなければならない。
次のことを完全に理解してほしい:Microsoft Windows XP Home Editionを Microsoft Windows NT4またはActive Directoryドメインセキュリティに統合したいと思っても それが出来ない。これを解決する唯一のオプションは、Microsoft Windows XP Home EditionからMicrosoft Windows XP Professional への アップグレードを購入することである。
Microsoft Windows XP Home Editionはどのようなタイプのドメインセキュリティ 機能に参加する能力は持っていない。Microsoft Windows 9x/Meと異なり、 Microsoft Windows XP Home Edition はネットワークにログオンする機能を 完全に欠いている。
このことは前にも説明したが、この事について、Sambaチームの誰かに 質問を問い合わせたり、メーリングリストに質問を投げないでほしい。なぜなら 「出来ないから」である。それが出来るとなると、それはMicrosoftとの間のライセンス に違反することになるので、それをしないことを推奨する。
ドメインとワークグループはネットワークブラウジングという言葉において 全く同等である。2つの違いは、ネットワークへの安全なログインのための、 分散認証データベースはドメインに関連づけられることである。 また、ドメインログオンサーバーに対して認証が成功したユーザーに対して 異なるアクセス権を付与できる。Samba-3はこの機能をMicrosoft Windows NT/200xと同じ方法で行う。
ドメインへのログオンするSMBクライアントは、ドメイン内のすべての他のサーバーが 同じ認証情報を受け取ることを期待している。ドメインとワークグループ のネットワークブラウズ機能は同一であり、この文書内の、ブラウジングに関する節 の中で説明される。ブラウジングはログインサポートとは直交する(互いに他方への影響 を考慮する必要のない)概念であることに留意してほしい。
シングルログオン(訳注:シングルサインオンか?)ネットワークモデルに関連する課題は この節で扱う。Sambaはドメインログオン、ネットワークログオンスクリプト、 ユーザープロファイルを、この節で扱う、Microsoft Windows for Workgrops とMicrosoft Windows 9x/Meクライアントに対してサポートする。
ドメイン中のSMBクライアントがログオンしようとした時、ログオンサーバーを探す 要求をブロードキャストする。最初にリプライするものが処理を行い、Samba 管理者がインストールした何らかの機構を使ってパスワードを認証する。 サーバー間でユーザーデータベースが共有されていないドメイン(つまり、サーバーが、本質 的にはワークグループサーバーでありながら、しかも自分はドメインに参加している と他に周知するようなドメイン)を作成することも可能である(お勧めはしないが)。 これは認証機構がドメインとはかなり異なるものでありながら、ドメインと密接に関係して いるということを示している。
これらの機能を使うことで、Sambaサーバー経由でクライアントのログオンの確認 させることができる。すなわち、ネットワークにログオンした時にクライアント側でバッチファイルを実行させ、 クライアントの個人設定、デスクトップおよびスタートメニューをダウンロードさせる。
Microsoft Windows XP Home edition はドメインに参加できず、ドメインログオン の使用が許可されない。
設定手続きの話に入る前に、Windows 9x/Meクライアントがログオンをどのように 実行するかを見ておくことにしよう:
クライアントは(それがいるサブネットのIPブロードキャストアドレスに
対して)NetLogon要求をブロードキャストする。これは、NetBIOSレイヤ
でのNetBIOS名 DOMAIN<1C> に送られる。クライアントは、最初に受け取った回答を選ぶ。
その回答には\\SERVER
という形式で、ログオンサーバーのNetBIOS
名を含む。1C
という
名前はドメインコントローラー(netlogonサービスを提供するSMB/CIFSサーバー)
によって登録された名前のタイプである。
クライアントがそのサーバーに接続し、ログオンし(SMBsessetupXを実行) し、次にIPC$共有に接続する(SMBtconXを使って)。
クライアントは次にNetLogon共有に接続し、そのスクリプトを検索する。 もしも見つかり、読み出しできるならば、クライアントはそれを取り出し 実行する。その後、クライアントはNetLogon共有の接続を切る。
クライアントは、サーバーにNetUserGetInfo要求を送り、プロファイル検索の ために使うユーザーのホーム共有を検索する。NetUserGetInfo要求の 応答はユーザーのホーム共有以外のものは含まれていないので、Windows 9x用のプロファイルは ユーザーのホームディレクトリ内になければならない。
クライアントはユーザーのプロファイルを検索するために
ホーム共有に接続する。その時、共有名とパスでユーザーのホーム共有を指定する
こともできる。例をあげると、\\server\fred\.winprofile
である。もしもプロファイルが見つかれば、それを適用する。
クライアントは次にユーザーのホーム共有を切断し、NetLogon共有に再接続し、
ポリシーファイルCONFIG.POL
を探す。もしも見つかれば、
それを読み、適用する。
PDCとWindows 9x/Me ログオンサーバー設定の主要な違いは以下の通り:
Windows 9x/Me ログオンサーバーでは、パスワード暗号化は不要である。しかし、 Microsoft Windows 98 以降、既定値では平文パスワードサポートが無効化され ていることに注意。システムとアカウントポリシー で記述されているレジストリの変更で再度有効に出来る。
Samba PDCは Windows 9x/Meログオンサーバーとしてどうさする。すなわち、 Windows 9x/Meが期待するネットワークログオンサービスを提供するということである。
わかりにくい点が残らないように、最後に幾つかコメントを記述する。 userモード以外でのセキュリティモードの時に、Sambaをドメインコントローラーと して設定してもよいかについては、さまざまな議論があった。技術的な理由で うまくいかないセキュリティモードは、share モードのセキュリティのみである。 domainモードとserver モードのセキュリティは、実際にはSMBのuserレベルの セキュリティの変形のようなものである。
この問題は、Samba がドメインコントローラーとして機能しているときに、 そのワークグループのドメインマスターブラウザーでなければならないかという 議論と密接に関連している。 純粋なMicrosoft Windows NTドメイン中では、PDCはDMBになるために選択に勝ち、 次に、DOMAIN<1B>というNetBIOS名を登録する。これはWindowsクライアントが DOMAIN<1C>名を探すためにネットワークログオンサーバー見つけるときに使う 名前である。DMBはドメインマスターブラウザーである。 ネットワークブラウジングの章、 WORKGROUPブラウジングの設定を参照のこと。 この問題も議論に密接に結びついている。 Microsoft PDC はDMBになるためにelectionに勝つことを期待するが、もしも 勝てない場合、electionはDMBになるためのelectionに負けたという内容を Windowsイベントロガー(訳注:イベントビューワ?)に、警告メッセージを 短い間隔で連続して出力する。この理由のため、SambaサーバーがPDCである ネットワーク中では、SambaドメインコントローラーをDMBとして設定するのが 賢いやり方である。
DOMAIN<1C>名を登録するSMB/CIFSサーバーは、ネットワークログオン サービスを提供するのでそのように処理する。DOMAIN<1B>名を 登録するサーバーはDMBであるすなわち、DOMAIN<1D>名 を登録されたすべてのマシンを含んでのブラウズリスト同期の責任を 持つと言うことである。後者は、存在しているローカルネットワーク セグメントで、すべてのNetBIOS名の登録監視に責任があるLMBである。 ネットワークログオンサービス(NETLOGON)はドメイン制御に関連して いているが、ネットワークブラウジングとブラウズリスト管理には関係 していない。1Cと1B/1Dの名前サービスはお互いに無関係である。
security = user以外のモードで Sambaドメインコントローラーを使うための設定の問題に戻ろう。 ユーザーからの接続要求を検証するためにSambaホストが他のSMBサーバーかドメイン コントローラーを使うように設定した場合、ネットワーク上の他のマシン (password server)は、Sambaホストよりもより 詳しくユーザーについて知っているという状況になる。99%のケースで、 この別のホストはドメインコントローラーである。ドメインモードセキュリティ で動作している場合、workgroupパラメーター は(すでにドメインコントローラーが持っている)Windows NTドメインの名前に 設定しれなければならない。もしもそのドメインがドメインコントローラー をまだ持っていない場合、ドメイン自体がないのと同じである。
すでに定義上PDCを持つドメイン用にSambaサーバーをドメインコントローラーとして 設定することは問題を発生させる。それゆえ、そのドメインに対してDMBになるようにと security = userを設定するようにSamba ドメインコントローラーをいつでも設定すべきである。この方法のみが公式にサポート される操作モードである。
通常/etc/passwd
に格納されるマシンアカウントは、マシン名に
“$”を追加した形である。いくつかのBSDシステムはユーザー名
に“$”を使うものが作成できない。最近のFreeBSDのバージョンはこの
制限が取り払われたが、それより古いものはまだ使われている。
問題はエントリを作る時に使われるプログラム中のみである。一度作成されると
問題なく動作する。まず“$”なしでユーザー名を作る。次に、エントリを
編集するために vipw
を使い“$”を追加する。
あるいは、最初からエントリをvipwで作っても良い。その際には固有のユーザーログインIDを使うように
すること。
マシンアカウントはワークステーションが持つ名前と同じ名前でなければならない。
UNIXのツールvipw
は直接/etc/passwd
を修正
する共通的なツールである。vipwを使うと(もしも使われているならば)shadowファイルが
パスワードファイルと同じになることを保証する。これはセキュリティの観点から重要
である。
“I get told,マシン信頼アカウント作成時に `You already have a connection to the Domain....' (既にドメインへの接続があります。) か `Cannot join domain, the credentials supplied conflict with an existing set...' (ドメインに参加できません。信用情報が既存のものと一致しません) が出ることについては以前に話した。”
これは、そのマシン自身からマシン信頼アカウントの作成を使用としたとき、 Samba PDC上の共有(かIPC$)にすでに接続している(つまりマップされたドライブ) がある時に起きる。以下のコマンドはすべてのネットワークドライブ接続を切断する:
C:\>
net use * /d
これはすべてのネットワーク接続を切る。
さらに、もしもマシンがすでに参加済みのドメインと同じ名前の “workgroupのメンバー”ならば(これはやってはいけない)、このメッセージが出る。 ワークグループを何か別の名前に変えて再起動し、 もう一度やってみる。
“ ドメイン参加に成功したが、Sambaのバージョンを新しくした後、ログオン時に `The system cannot log you on (C000019B). Please try again or consult your system administrator (システムはあなたのログオンを許可できません(C000019B)。後ほど再試行するか、システム管理者に相談してログオンしてください) というメッセージが出た。'”
これはsecrets.tdbに格納されているドメインSIDが変わったことによって引き 起こされるものである。ドメインSIDが変わるよくある理由は、ドメイン名 かサーバー名(NetBIOS名)が変わったことである。問題を解決する唯一の方法は オリジナルのドメインSIDに戻すか、クライアントをいったんドメインから 削除して再参加することである。ドメインSIDは、netまたはrpcclient ユーティリティによってリセットすることも出来る。
ドメインSIDをリセットしたり、変更するには、以下のようにnetコマンドを 使用する:
root#
net getlocalsid 'OLDNAME'
root#
net setlocalsid 'SID'
ワークステーションのマシン信頼アカウントはドメイン(またはネットワーク) SIDでのみ動作する。このSIDが変更されると、ドメイン メンバー(ワークステーション)はドメインにログオンできない。オリジナルの ドメインSIDはsecrets.tdbファイルから復元できる。別の解は、おのおのの ワークステーションが再度ドメインに参加することである。
“ドメインに参加しようとした時 "The machine account for this computer either does not exist or is not accessible (このコンピューターのマシン・アカウントは存在しないか、アクセスできません) ." というメッセージが出た。何が悪い?”
この問題は、PDCが適切なマシン信頼アカウントを持っていないことに起因 する。アカウント作成時に add machine scriptという方法を使った場合、 このメッセージは、アカウント作成に失敗したことを示している。ドメイン管理ユーザー のシステムが 動作しているかを確認して正常動作するようにすること。
かわりに、手動でアカウントエントリを作成していた場合、正しく作られていない
ということである。Samba PDC上でsmbpasswd
ファイル
中のマシン信頼アカウントのエントリが正しく出来たかどうかを確認する。もしも、
smbpasswd ユーティリティを使わないでアカウントをエディターで追加した場合、
アカウント名をマシンのNetBIOS名に“$”を追加して(すなわち、
computer_name$)おくこと。これはSambaSAMAccountバックエンドと同じように
POSIX UNIXシステムアカウントバックエンドの両方の中に存在する必要がある。
Samba-3の既定値のバックエンド(すなわち、パラメーター
passdb backend
)はsmb.conf
ファイル中で指定されて
おらず、また、もしも指定されているものがsmbpasswd
だった場合、それらはそれぞれ/etc/passwd
と
/etc/samba/smbpasswd
(あるいはもしもSambaチームの
既定値の設定を使ってコンパイルした場合は
/usr/local/samba/lib/private/smbpasswd
)である。
/etc/passwd
の使用はNSS /etc/nsswitch.conf
ファイル中の別の設定で上書きすることが出来る。
SambaサーバーとNTクライアントの間のサブネットマスクの不一致により、この問題が起こると いう報告も一部から上がっている。クライアントとサーバー両方で整合性 を取るようにすること。
“NT4/W200xワークステーションからSambaドメインにログオンしようとした とき、アカウントが無効になっているメッセージが出た。”
smbpasswd -e
。これは通常アカウント作成時に行われる。
username
でユーザーアカウントを有効化する
“Sambaが開始してから数分間、クライアントがエラー`Domain Controller Unavailable' (ドメイン・コントローラーが使えません。)を表示する。”
ドメインコントローラーはネットワーク上にその役割をアナウンスする。これは通常しばらくかかる。最低15分は待ち、 再度試してみること。
ドメイン参加成功後、2つのメッセージのうちの1つが出てユーザーログオンに失敗する: 1つはドメインコントローラーが見つからないというもので、もう1つはアカウントが ドメインにないか、パスワードが違うというものである。これは、schannel (セキュアchannel)の設定か、smb 署名の設定について、 WindowsクライアントとSamba-3サーバーにおいて設定の不一致によるものと考えられる。 以下を実行して、Sambaの client schannel、server schannel、 client signing、server signingの設定と それらの値について確認すること:
testparm -v | grep channel
また、MMC ローカルセキュリティの設定を使うこと。このツールはコントロール パネルにある。ポリシーの設定は、ローカルポリシー/セキュリティオプション領域にあり、 Secure Channel:..., and Digitally sign...(セキュリティチャネル、 デジタル的に署名) という言葉を含んだ項目で設定する。
これらが Samba-3 サーバー設定と一致した設定になっていることが大切である。
Table of Contents
このセクションを読み始める前に、ドメイン制御 中で説明されているSambaドメインコントローラーの設定に問題がないようにして おくこと。
この章は、説明するのが最も困難な章の一つである。何を書いても、誰かがまだ 実現できていない項目、あるいはまったく異なるアプローチを使った方が遥かに 効果的に実現できる項目について、実現されたはずだと期待してSambaチームに 問い合わせてくることを防止することはできないと思われる。もしこの章で説明 されているはずなのに、いくら読んでも言及されない事項というのがある場合は、 要件あるいは質問内容を明確に書いて John H. Terpstra まで電子メールで問い合わせてほしい。
Samba-3 は別のSambaプライマリドメインコントローラー(PDC)に対するバックアップ ドメインコントローラー(BDC)として機能することができる。Samba-3 PDCは、LDAP アカウントバックエンドとともに運用することができる。LDAPバックエンドは、 共用のマスターLDAPサーバーかスレーブサーバーのどちらでも使える。スレーブLDAPサーバー を使用する利点は、マスターがダウンしている時でもクライアントがネットワークに ログオンできるということである。これによりSambaが高いレベルの拡張性を持つ ことになり、大規模な組織のための効果的なソリューションとなり得る。PDCにLDAP スレーブサーバーを使用する場合、マスターの継続的な可用性を確保する必要がある。 悪い時にスレーブ側から見てマスターがダウンしていると、安定性の問題や運用上の 問題となる。
Samba-3 BDCをLDAPでないバックエンドとともに運用することも可能だが、 バックエンドが何らかの形で「双方向の」伝達を許容し、BDC側からマスター への変更が可能であるようにしなければならない。現段階でこれをできるのは LDAPのみである。PDCが、そのプライマリとしてLDAPマスターサーバーを使うことが 好ましい間、BDCはスレーブLDAPサーバーを使うことが出来る。
LDAPでないバックエンドSAMデータベースを使用するのは問題に陥りやすくなる。 なぜなら、ドメインメンバーサーバーもワークステーションも、マシン信頼アカウントの パスワードを定期的に変更するからである。新しいバスワードはローカルでしか保存 されない。このことは、(LDAPベースのソリューションにあるような)集中的に格納 されたアカウントデータベースが無く、Samba-3 がBDCとして動作しているとき、 BDC 側のドメインメンバー信頼アカウントのパスワードの記録が、PDC(マスター)のSAM のコピーに届かないことを意味する。もし、PDCのSAMがBDC側に複製されると、 最新の(変更後の)信頼アカウントのパスワードを含むSAMが上書きされることになり、 ドメイン信頼が無効になってしまう。
BDCの設定方法に関して挙げられたコメントや質問の数が多いので、可能な選択肢の 一つ一つについて、おのおのの解について利点欠点を見てみよう。 以下のドメインバックエンドアカウント分散オプション一覧 は、PDC/BDC構成で設定可能な設定例の一覧である。
Table 5.1. 分散ドメインバックエンドアカウントの選択肢
PDCバックエンド | BDCバックエンド | 補足事項 |
---|---|---|
マスターLDAPサーバー | スレーブLDAPサーバー | 高い整合性を提供する完全なソリューション。SAMは共通マスターLDAPサーバーで 複製される。 |
単一の集中LDAPサーバー | 単一の集中LDAPサーバー | フェイルオーバー機能がないが実用可能なソリューション。これは実用的なソリューションで あるが、完全ではない。 |
tdbsam | tdbsam + | Samba-3.0では動かない。Sambaはサーバーサイドプロトコル要求を実装していない。 |
tdbsam | tdbsam + | この設定を使ってはいけない。TDBファイルが使用中の状態でデータがディスクに 完全に書き戻されていないかもしれないので、動作しない。 さらに、ドメインの信頼関係を壊すだろう。 |
smbpasswd file | smbpasswd file | この設定を使ってはいけない。 同期が遅延するためにエレガントな解ではなく、ドメイン信頼関係 の問題で悩むだろう。 |
ドメインコントローラーは、ネットワーク上のワークステーションからのログオン 要求に答えることが出来るマシンである。Microsoft LanManagerとIBM LanServer はこの機能を提供していた初期のプロダクトの2つである。その技術は、LanMan NetLogonサービスとして知られるようになった。
Microsoft Windows NT3.10 の最初のリリースで、新しいドメイン制御形式が サポートされ、同時に機能を拡張した新しい形のネットワークログオンサービスが サポートされることになった。このサービスは、NT NetLogon サービスとして知ら れている。このサービスの性質は、 Microsoft Windows NT の進化に伴って変更され、 今日では洗練された各種技術の上に広範で複雑な各種サービスを実現している。
NT4/200x/XP Professionalワークステーションにユーザーがログオンするときは いつでも、ワークステーションはユーザーが入力したユーザー名/パスワードペア が正しいかを検証するためにドメインコントローラー(認証サーバー)に接続する。 もしも入力された情報がドメイン制御データベース(SAM、すなわちセキュリティ アカウントマネージャデータベース)に格納されているアカウント情報と 一致しない場合、認証要求を出したワークステーションに一連のエラー コードを返す。
ユーザー名/パスワードペアが検証されたとき、ドメインコントローラー(認証サーバー) はそのドメインに対するユーザーとマシンアカウントデータベース中の、そのユーザー に関係するアカウント情報の完全な項目一覧を返す。この情報はそのユーザーに対する 完全なネットワークアクセスプロファイルを含むが、ユーザーのデスクトッププロファイル に特有の情報は含まないか、あるいはそれに関して、ユーザーが属してもよいグループ のためのすべてのデスクトッププロファイルも含まれない。また、それには、 パスワード満了時間、パスワードの一意性制御情報、ネットワークアクセス時間制限 情報、アカウント検証情報、ユーザーがアクセスできるネットワークからのマシン名 や空にその他の情報が含まれている。すべての情報はMicrosoft Windows NT(3.10, 3.50, 3.51, 4.0)バージョン中のSAM中に格納される。
ドメインコントローラー上のアカウント情報(ユーザーとマシン)は2つのファイルに格納
される。そのうちの1つにはセキュリティ情報を含み、もう1つはSAMである。それらは
%SystemRoot%\System32\config
ディレクトリ中に同名の
ファイルに格納される。これは通常C:\WinNT\System32\config
に変換される。ネットワーク上にBDCがあるとき、この2つのファイルがSAMデータベース
の複製に関与するファイルである。
BDCをインストールすることが好ましい状況が2つある:
真のWindows NT4環境中でのPDCとBDCのやりとりについてここで触れておく。PDCは SAMのマスターコピーを持っている。管理者がPDCの持つローカルネットワーク上に物理的に 存在するユーザーアカウントデータベースに変更を加えると、この変更内容は、SAMの マスターコピーのPDC上の記録に直接行われる。 このような情報更新が別のオフィスで行われると、この変更内容はローカルBDC 上の差分ファイルに格納される。BDCはその後SAM同期を行うプロセスを開始するために、 PDCに対してトリガを送る。PDCは当該ドメインの全BDCに接続し、全BDCが更新情報を入手し、 それぞれのSAMのコピーに最新の情報を反映させるようにトリガを出す。
Samba-3は真のSAM複製に参加できないので、Microsoft Windows NT4で 使われているのと同じプロトコルを使用することが出来ない。 Samba-3 BDCはSAM更新差分ファイルを作成できない。BDCが持っている差分 ファイルからSAMの同期をとるために、PDC(NT4またはSamba)間とやりとりもしない。
Samba-3 はMicrosoft Windows NT4 BDCとしては動作できず、Samba-3は Microsoft Windows NT4 BDCに対するPDCとして正しく動作できない。 Samba-3とMicrosoft Windows NT4はそれぞれのタイプのPDCへのBDCとして 機能することは出来る。
BDCはネットワークログオン要求とユーザー認証が出来るので、 読み出し専用のSAMを保持していると言える。 BDCはこのサービスを提供し続けることができる。特に、PDCへのWANの リンクがダウンしている場合などに有効である。BDCは、ドメインの セキュリティとネットワークの整合性の維持に大変重要な役割を果たす。
NT4のPDCを稼働停止しなければならない場合や故障した場合、NT4 のBDCの
一つをPDCに昇格することができる。このようなことを NT4 PDCがオンライン
中に行うと、NT4 PDCは自動的に NT4 BDCに降格する。これはドメインコントローラー
の管理の中で特に重要な一面である。昇格および降格を実行するのに使用される
ツールはドメインサーバーマネジャーである。ここで注意しなければならない
ことは、Samba-3 の BDCは同様の方法で格上げすることはできないということである。
これは、そのような Samba の再設定を行うにはsmb.conf
ファイルの変更が必要に
なるからである。作業は、smb.conf
ファイルの手動での変更と、Sambaネットワーク
サービスに関連するものの再起動をおこなうだけでよい。
バージョン2.2の最初からSambaは公式に、Windows NT4、2003とXP Professional
を含む現行Windowsクライアントすべてでドメインログオン機能を公式にサポート
している。PDCを有効にしたSambaではsmb.conf
中の[global]
セクション内にいくつかのパラメーターを設定しなければならない。最低限
必要な設定の例はBDCと共に使う、PDC上にLDAP
サーバーがあるPDCのための最低限のsmb.conf の節
を参照のこと。
[homes]
と[netlogon]
共有などの項目や、プロファイルパス、ユーザーのホームドライブや
その他を設定するための設定も一緒に行う必要がある。それらはこの章では
触れない。詳細な情報については、ドメイン制御
を参照のこと。PDC設定のための特定の推奨パターンは
ドメイン制御の章を参照のこと。また別に、
地域の、あるいはオンライン書店から入手できる“Samba-3 by Example”という
書籍(book)
中にOpenLDAPとSambaのネットワーク動作設定例が完全に記述されている。
マスターとスレーブLDAPサーバーを設定する時、マスターLDPサーバーをPDCに、スレーブLDAPサーバー をBDCで使うことが推奨される。スレーブLDAPサーバーを使うことは不可欠ではないが、 サービスの冗長性を提供するために多くの管理者はそのことを好んでいる。もちろん、 1つ以上のBDCがどののスレーブLDAPサーバーを使ってもかまわない。また、 ネットワーク全体で1つのLDAPサーバーを使うことも可能である。
スレーブLDAPサーバーサーバーを持つマスターLDAPサーバーを設定する時、このことを
/etc/openldap/slapd.conf
ファイル中に設定する
ことを忘れないように。サーバー証明書のDNは、サーバーの名づけるためにCN属性を
使わなければならず、CNはサーバーの完全に的確性のあるドメイン名を含んでいなければ
ならないことに注意。証明書の subjectAltNameエクステンション中に追加の別名や
ワイルドカードを持っていても構わない。サーバー証明書についてのより詳細
な情報はRFC2830を参照のこと。
この文書の範囲内にはうまく一致しないが、LDAPをインストールすることは、LDAPを
有効にしているSamba操作の基本である。トランスポートレイヤのセキュリティ
(TLS)を有効にしてOpenLDAPを使う場合、/etc/ssl/certs/slapd.pem
中のマシン名は/etc/openldap/sldap.conf
と同じものである
必要がある。Red Hat Linuxスタートアップスクリプトはホスト名として、
“localhost.localdomain”としたslapd.pem
ファイルを生成する。これだと、正しいホスト名で証明書が再作成されない限り、
スレーブLDAPサーバー(すなわちSamba BDC)からLDAPサーバーにアクセスできない。
LDAPスレーブサーバーを使うようにSamba PDCをインストールしてはいけない。ドメインへ クライアントマシンを参加する時、LDAPデータベース中へのマシンアカウントの変更がマスター LDAPサーバー上で行わなければならないという理由で、この設定ではうまくいかない。 PDCが出した問い合わせがスレーブサーバーに複製されるまで時間がかかりすぎる。そのため、 クライアントマシン上で、アカウントの証明書がセットアップできないというエラー メッセージが出る。LDAPサーバー上でマシンアカウントが作成されるが、パスワード欄は空となる。 残念なことに、いくつかのサイトはこのような設定を防げず、そのため、それらのサイトでは、 複製に追いつくために、Sambaの処理を十分に遅くするための、 ldap replication sleepパラメーターを検討すべきである。 これは、その場しのぎの解決方法であり、管理者が何らかのスクリプト(たとえば、 add machine scriptのようなもの)を使って手動で複製 しなければならない。
PDC/BDCとLDAPを使う、設定可能なパターンは以下の通り:
PDC+BDC -> 1つの集中LDAPサーバー。
PDC -> LDAP マスターサーバー、 BDC -> LDAPスレーブサーバー。
PDC -> LDAPマスター、第二のスレーブLDAPサーバーあり。
BDC -> LDAPマスター、第二のスレーブLDAPサーバーあり。
PDC -> マスター、第二のスレーブLDAPサーバーあり。
BDC -> スレーブ、第二のスレーブサーバーあり。
(セカンダリ)LDAPサーバーサーバーを持つためには、
smb.conf
に記述する複数LDAPサーバーの例
のように指定する。
Microsoft Windows 2000とActive Directoryのリリース以降、この情報は 複製可能で、管理コントロールの部分的あるいは全体を複製できるディレクトリ 中に格納される。Samba-3はActive Directory内でドメインコントローラー にはなれず、また、Active Directoryサーバーにもなれない。このことは、Samba-3 はActive DirectoryドメインコントローラーのBDCとなりえないことを意味する。
ドメインMIDEARTH用のドメインコントローラーであるすべてのマシンは、 WINSサーバーかローカルネットワークに対するブロードキャストを使って NetBIOSグループ名MIDEARTH<1C>を登録しなければならない。 またPDCはWINSサーバーで一意のNetBIOS名MIDEARTH<1B>を登録する。 名前タイプ<1B>はドメインマスターブラウザー(DMB)のために通常予約ていて、 認証には通常何ら関係ないが、Microsoft ドメインの導入時はDMBがPDCと同じマシンであることが用件となる。
WINSサーバーを使っていないとき、名前登録はブロードキャストするだけで 十分なはずである。ネットワークブラウジング とDiscussionに、TCP/IPネットワーク プロトコル関連と、どのようにSMB/CIFS名を取り扱うかについてのより詳細な 情報があるので参照すること。
ドメインコントローラーを見つけるメカニズムは2つある:1つは NetBIOS over TCP/IPが有効なときに使われ、もう1つはTCP/IPネットワーク設定 で無効になっているときに使われるものである。
NetBIOS over TCP/IPが無効になっているとき、すべての名前解決は、 Active Directory通信技術のような、DNS、UDP上のブロードキャストを使う。 このタイプの環境では、すべてのマシンが適切なDNSエントリを持つことが必要である。 より詳細な情報はDNSとActive Directory を参照のこと。
ドメインMIDEARTH内のMicrosoft Windows NT4/200x/XP Professional ワークステーションがローカルユーザーを認証させたい場合、 MIDEARTHのドメインコントローラーを見つける必要がある。これは、グループ名 MIDEARTH<1C>に対するNetBIOS名前解決を行うことによって行われる。 ワークステーションは、問い合わせに返事を返すマシンの1つ1つがドメインコントローラーで あり、ログイン要求に答えることが出来ることを仮定している。セキュリティ ホールを造らないために、ワークステーションと選択されたドメインコントローラー はおのおのを認証する。その後、ワークステーションはユーザーの認証情報( ユーザー名/パスワードペア)を認証のためにローカルのドメインコントローラーに 送る。
realm quenya.org
中の
Microsoft Windows NT4/200x/XP Professional workstationが
ユーザーログオン認証をしたい場合、DNSサーバーに対して
_ldap._tcp.pdc._msdcs.quenya.org
レコードを
再度問い合わせすることでドメインコントローラー見つける。
この項目に対する関連したより詳細な情報は、
DNSとActive Directoryを参照のこと。
BDCの作成には最初にsmbdを動かす前にSamba サーバーを準備するため のいくつかのステップが要求される。
ドメインSIDはPDCとBDCで同じにしなければならない。バージョン2.2.5
以前のSambaでは、ドメインSIDはprivate/MACHINE.SID
ファイルに格納されていた。Sambaバージョン2.2.5以降すべてのバージョンでは、
ドメインSIDはprivate/secrets.tdb
ファイルに
格納されている。このファイルは各サーバーで固有であり、PDCからBDCに
コピーできない。BDCは新しいSIDを起動時に生成する。新しく生成したBDCのSID
はPDCのドメインSIDを上書きする。これは、BDCにドメインSIDを入手することを
認める手続きである。これについては以下で説明する。
PDCまたは既存のBDCからドメインSIDを検索するためと、検索した値を
secrets.tdb
に格納するためには、以下を実行する:
root#
net rpc getsid
ldap admin dnの指定は必須である。
また、smbpasswd -w
を使って、mysecret
secrets.tdb
中にLDAP管理用パスワードを
設定しなければならない。
The ldap suffixパラメーターとldap idmap suffix
パラメーターはsmb.conf
ファイル中で指定しなければならない。
UNIXユーザーデータベースはPDCからBDCへ同期しなければならない。
これは、/etc/passwd
と
/etc/group
の両方がPDCからBDCに複製されなければ
ならないことを意味している。これは変更が発生した時点で、手動で
行うことが出来る。別のやり方として、PDCをNISマスターサーバーとして設定し、
BDCをNISスレーブサーバーとして設定する。BDCをNISクライアントとして設定
するのでは、PDCが止まっているときにそのユーザーデータベースにアクセス
出来ないので不十分である。NISはパスワード同期の唯一の手法というわけ
ではない。LDAPを使う解も同様に動作する。
SambaパスワードデータベースはPDCからBDCに向けて複製されねばならない。
rsync
とssh
でsmbpasswd
ファイルの同期を取るのが可能であるが、この方法は破綻していて
欠陥があるので推奨できない。よりよい解決方法は、各BDCに対してスレーブ
LDAPサーバーを、PDCにマスターLDAPサーバーを設定することである。
rsyncを使う方法は、一定間隔毎にデータが複製されるという理由で、本質的に
欠陥がある。すべての瞬間に、現在のマシンとユーザーアカウントの正しい情報で
BDCが操作できるという保証がない。このため、この方法では、首尾一貫しない
セキュリティデータのために不連続なネットワークサービスへのアクセスによって
ユーザーに不都合が生じる危険性がある。Windows ワークステーションが通常の
間隔でマシン信頼アカウントパスワードを更新(変更)することを心にとめて
おかねばならず、管理者は通常それが起きていることを知らない。
POSIX(UNIXユーザーとグループ)アカウントとSambaSAMAccountデータ両方のために LDAPを使うと、すべてのアカウント変更情報が共有ディレクトリに書かれること を自動的に保証する。これは、LDAPがその要求に適合するため、アカウント情報の 同期のための、何らかの特別な動作が必要ないことを意味する。
netlogon共有はPDCからBDCに向けて複製されねばならない。これは、ログインスクリプト
が変更されるたびごとに手動で行うことができ、また、rsync
のような
ツールを使うことで、この共有中のディレクトリ構造を複製する、cron
ジョブを使うことで自動的に行える。netlogon共有内のファイルの複製に
rsync
を使うことは、ネットワークセキュリティに対して特段
問題になることはない。管理者が netlogon 共有に対するすべての変更を明示的に
行ないたいと考えている場合は、手作業で管理するために用いることも可能である。
最後に、ワークステーションがBDCを見つけなければならない。
これは、SambaをBDCになるための最低限の設定中にある
Samba smb.conf
ファイルの[global]
セクションのように設定
することで行える。
Example 5.3. BDCになるための最低限の設定
完全な、OpenLDAPとSambaを使うネットワーク設定の例の説明は、近所又はオンライン 書店で買える、“Samba-3 by Example”という 本 を参照のこと。
この設定はWINSサーバーに、MIDEARTH<1C>という名前のみをBDCによって 登録させる。これは、MIDEARTH<1C>というNetBIOSグループ名が、 複数のマシンが登録に使用することを意図した NetBIOS グループ名であることを 考えれば問題ではない。パラメーター domain master = noは、PDCのために 予約されている固有のNetBIOS名であるMIDEARTH<1B>をBDCが登録時に 使用させないことを確保する。
idmap backend
パラメーターが、
winbindd
ユーティリティをリダイレクトして、共有される
リポジトリ内にある、
UNIXアカウントに関するすべての、Windows SIDからUIDとGIDへの解決のために
LDAPサーバーデータベースを使用させる。
BDCはnss_ldap
ユーティリティとNSS経由の、ローカルでのUIDとGIDの
解決にも依存する。
Samba-3は新しいIDマッピング機能を導入した。その機能の特徴の1つは、
NTドメインのユーザーとグループSIDに関してユーザーとグループIDを取り扱うやり方に、
より高い柔軟性を備えているということである。新しい機能の1つは、UNIX/Linuxの
UIDとGIDの値が、PDC、すべてのBDCとすべてのドメインメンバーサーバー上で
一貫していることを明確に確保する。これを制御
するパラメーターは、idmap backend
である。その動作
に関連する詳細な情報は、smb.conf
マニュアルページを参照してほしい。
BDC上のみでidmap backend = ldap:ldap://master.quenya.org オプションを使用することは、PDC上でldapsamが使われている時に意味をなす。 LDAPベースのバックエンドのもう1つの目的は、(固有のpassdbバックエンドを持たない)ドメインメンバー がWindowsネットワークユーザーとグループを共通のUID/GIDに割り当てるためにwinbindd を使えるようにすることである。別の言い方をすると、一般的にこのオプションは、 BDCとドメインメンバーサーバー上で使うことを意図している。
ドメイン制御はSambaの新しい領域であるが、現在では参照可能なたくさんの事例がある。
更新情報は、それが有効になった時点で、Sambaの新規リリース情報か、
Samba Websiteで公開される。
SambaリリースパッケージのWHATSNEW.txt
を特に参照すること。
“Samba-3 by Example”という本には、よくテストされ、検証された
例が記述されている。これをSamba Webサイト上の
本
からコピーを入手することもできる。
この問題は、passdb(SAM)ファイルが中央のサーバーからコピーしていて、しかもローカルのBDC がPDCとして動作する時に発生する。これはローカルマシン信頼アカウントのパスワードを ローカルSAMへ更新を実行することで解決する。そのような更新は中央の サーバーにコピーは戻されない。新しいマシンアカウントのパスワードは、PDCからの SAMが再度コピーされたときに上書きされてしまう。その結果、起動時のドメインメンバー であるマシンの起動時に、そのパスワードがデータベース中と一致しないことになり、起動時の セキュリティチェックに失敗するため、このマシンはログオン要求が許可されず、 アカウント満了エラーが出ることになる。
解決策は、ldapsamバックエンドのようなより堅牢なpassdbバックエンドを使うことである。 すなわち、各BDCにスレーブLDAPサーバーを立て、PDCにマスターLDAPサーバーを 立てることである。
できない。オリジナルのNT4 SAM複製プロトコルはまだ完全に実装されていない。
SambaでBDCを使う利点はあるかと言われればもちろんある。しかし、それはSamba PDCに対して のみである。BDCを使う理由は可用性という点である。もしもPDCがSambaだった 場合、2番目のSambaマシンは、PDCがダウンしている時にログオン要求 をサービスするように設定できる。
smbpasswdファイルの複製は注意が必要である。SAMが変更されたときは必ず 行わなければならない。各ユーザーのパスワードの変更はsmbpasswd ファイル中で行われるので、必ずBDCに複製されねばならない。そのため、smbpasswdファイル の複製は非常に頻繁に必要となる。
smbpasswdファイルには平文パスワードと同等のものが含まれているので、ネットワーク
上で暗号化しないで送ってはならない。PDCからBDCへ、smbpasswdを複製する最もよい方法
は、rsyncを使うことである。rsyncは伝送路としてsshを使える。
ssh
は、ユーザーがパスワードを入力
しなくてもrsync
での転送ができるように設定できる。
少し前に説明したが、この方法を使うことは欠陥があるため危険である。マシン信頼 アカウントの同期が外れると、結果としてドメインが破壊される。この方法は 推奨されない。その代わりにLDAPを使うこと。
Table of Contents
ドメインメンバーシップはきわめて重要な事項である。Sambaは Microsoftドメインセキュリティコンテキスト中においてメンバーサーバーとして 参加できねばならず、Sambaはドメインマシンメンバー信頼アカウントを 付与できねばならない。これなしには多くのユーザーに実行可能なオプション を提供できないだろう。
この章では、ドメインメンバーシップに関する背景情報、Sambaの設定と、 Microsoft Windows クライアントのドメインに参加方法について説明する。 なぜそれが必要なのであろうか?なぜならば、現在のMicrosoft Windows ネットワーキングと、特にUNIX/Linuxネットワーキングおよび管理の世界に関して かなりの間違った情報、誤解があり、また知識の欠如が顕著だからである。 この章によってその欠如を埋めることを望みたい。
Microsoft Windows ワークステーションおよびサーバーがドメイン セキュリティに参加するためには、ドメインメンバーにならなければならない。 ドメインセキュリティに参加することは、しばしばシングルサインオン か省略してSSOと呼ばれる。この章では、ワークステーション (かあるいはMicrosoft Windows NT4/200xサーバーであるもう一台のサーバー) 又はSambaサーバーを、Microsoft Windowsドメインセキュリティの メンバーにするための手順について説明する。
Samba-3 はNT4形式のMicrosoft Windowsドメインにネイティブなメンバーサーバー として、Microsoft Windows Active Directoryドメインにネイティブな メンバーサーバーとして、あるいは、Sambaドメイン管理ネットワークに参加 できる。ドメインメンバーシップはたくさんの利点を持つ:
ドメインユーザーアカウントの(アクセス)権限とファイルの所有権およびアクセス制御は 単一のドメインセキュリティアカウントマネージャ(SAM)データベース から設定できる(ドメインメンバーであるMicrosoft Windowsワークステーション と同様にドメインメンバーサーバーで動作する)。
ドメインメンバーであるMicrosoft Windows NT4/200x/XP Professional ワークステーションのみがネットワークログオン機能を使える。
ドメインメンバーのワークステーションを、ポリシーファイル
(NTConfig.POL
)およびデスクトッププロファイルを使用
してよりよく制御できる。
ログオンスクリプトを使用することで、ユーザーはアプリケーションサーバー 上のネットワークアプリケーションへ自由にアクセスできる。 (訳注:意味はこれでよい?)。 Through the use of logon scripts, users can be given transparent access to network applications that run off application servers.
ネットワーク管理者にとっては、より優れたアプリケーション管理およびユーザーアクセス 管理が可能になる。ユーザーアカウントを、中央にあるドメインデータベース (NT4/SambaでのSAM形式ドメインか、LDAPによるディレクトリがバックエンドになった NT4ドメインか、Active Directory基盤経由で)以外の任意のネットワーク クライアントかサーバー上でユーザーアカウントを保守する必要がないからである。
マシン信頼アカウントは(ユーザーではなく)クライアントマシンを ドメインコントローラーサーバーに対して認証するために使われる。Windowsの用語では、 これは“コンピュータアカウント”として知られている。 マシン信頼アカウントの目的は、不正(訳注:rogue)ユーザーとドメインコントローラー が、共謀してドメインメンバーのワークステーションにアクセスすることを 防ぐことである。
マシン信頼アカウントのパスワードは、ドメインコントローラーとの間で暗号化 通信を行うために共通の秘密鍵(訳注:shared secret:共通鍵?)である。 これは、同じNetBIOS名を持つ未認証マシンがドメインに参加し、ドメインセキュリティ 操作をし、ドメインユーザー/グループアカウントへアクセスすることを得ることを防ぐ セキュリティ機能である。Windows NT/200x/XP Professionalクライアントは マシン信頼アカウントを使うが、Windows 9x/Me/XP Homeは使わない。従って、 Windows 9x/Me/XP Homeクライアントは、マシン信頼アカウントを持たないため、 ドメインコントローラーとの間で、共通の秘密鍵を持つことはなく、決してドメイン の真のメンバーにはなれない。
Windows NT4 PDCはマシン信頼アカウントをWindowsレジストリ中に格納する。 Microsoft Windows 2000の登場と共に、Active Directoryという、 マシン信頼アカウントのための新しいリポジトリが登場した。それに対し、 Samba PDCはマシン信頼アカウントを以下のように2つの部分に分けて格納する:
ドメインセキュリティアカウントはsmb.conf
ファイル中で設定される
passdb backendに格納される。格納される
アカウント情報の性質は、選択されたバックエンドデータベースの
タイプに依存する。
このデータのより古い形式はsmbpasswd
データベースで、
そこにはUNIXのログインID、UNIXのユーザー識別子(UID)、LanManおよびNT形式で
暗号化されたパスワードを格納している。また、ここでは触れないが、その他
にもいくつかの情報が含まれている。
より新しいデータベースは、ldapsamとtdbsamと呼ばれる。どちらも、以前の
smbpasswd
ファイルよりもかなりより多くのデータを格納する。
その付加情報により、新しいユーザーアカウント管理の新しい方法が可能になる。
対応するUNIXアカウントは通常/etc/passwd
に格納される。
UNIX ユーザーアカウントを必要としないような、より簡便なオペレーションの実現
に向けて開発中だが、この機能は Samba-3 の初期リリースまでは実装されない予定
である(訳注:この部分は古い)。
UNIX/Linuxコマンド行からの手動作成。この方法では、Sambaとそれに対応する UNIXアカウントが手動で作成される。
NT4ドメインコントローラーからMicrosoft Windows NT4サーバーマネージャを使うか、 MicrosoftのWebサイトから入手可能なNexusツールキットを使う。このツールは ユーザーが管理者アカウントでログオンしている限り、任意のMicrosoft Windows マシンから実行することが出来る。
“その場での(on the fly)”作成。Sambaマシン信頼アカウントは、 クライアントがドメインに参加したときに、Sambaによって自動的に作成 される(セキュリティ上、この方法が推奨される)。対応するUNIX アカウントは自動でも、手動ででも作成できる。
Microsoft Windows NT4/200x/XP ProfessionalもSambaもマシン信頼アカウントを 強制する方法を提供しない。これは管理者の選択問題である。
マシン信頼アカウントの手動作成の最初の手順は、/etc/passwd
中に対応するUNIXアカウントを手動で作成することである。
この作業は、vipw
か、通常、新規のUNIXアカウント作成時に
使われる“adduser”コマンドを使用する。以下は、Linux
ベースのSambaサーバーにおける例である:
root#
/usr/sbin/useradd -g machines -d /var/lib/nobody \ -c
"machine nickname"
\ -s /bin/falsemachine_name
$root#
passwd -l
machine_name
$
上記の例では、全マシンアカウントのプライマリグループとして使われる “machines”という、既存のシステムグループがある。以下の例では、 “machines”グループのGIDは100である。
*BSDシステム上では、この作業はchpass
ユーティリティを使うこと
もできる:
root#
chpass -a \ '
machine_name
$:*:101:100::0:0:Windowsmachine_name
:/dev/null:/sbin/nologin'
/etc/passwd
のエントリは“$”を追加した
マシン名を付けたもので、パスワードは持たず、シェル情報が空白で(訳注:
/dev/nullを指定すること)、ホームディレクトリの定義がない。たとえば、
マシン名が“doppy”の場合は/etc/passwd
のエントリは以下のようになる:
doppy$:x:505:100:machine_nickname
:/dev/null:/bin/false
上記の例では、machine_nickname
はクライアントに対する
任意の名前を記述する(たとえばBasementComputer)。
machine_name
はドメインに参加するときの
クライアントのNetBIOS名でなければならない。“$”を
クライアントのNetBIOS名に必ず付加しなければならず、これがないと、
Sambaはこれをマシン信頼アカウントと認識できない。
対応するUNIXアカウントが作成されると、次の手順は初期マシン信頼
アカウントの、よく知られたパスワードを持つクライアント用のSamba
アカウントを作成することである。
これは以下に示すようなsmbpasswd
を使用する:
root#
smbpasswd -a -m
machine_name
ここでmachine_name
はマシンのNetBIOS名である。
新規のマシンアカウントのRIDは対応するUNIXアカウントのUIDから生成される。
有効なadd machine scriptはマシン信頼アカウントの 自動作成に必須である。これは自動アカウント作成機能を使用する場合でも、 NT4 ドメインサーバーマネージャを使用する場合でも必要である。
ドメインを管理しようとしているマシンが
Microsoft Windows NT4 ワークステーション又はMicrosoft Windows 200x/XP Professional
の場合、使用するツールはSRVTOOLS.EXE
という
パッケージである。これをターゲットディレクトリで実行すると、SrvMgr.exe
及びUsrMgr.exe
(どちらもMicrosoft Windows NT4 ワークステーション
のドメイン管理ツール)が解凍される。
ワークステーションがMicrosoft Windows 9x/Me
ファミリー製品であれば、 Microsoft のWebサイトからNexus.exe
パッケージをダウンロードする。それをターゲットディレクトリから実行すると、
上記と同じツールで、9x/Meプラットフォーム用のものが解凍される。
これらのツールに関する詳細情報は次のKnowledge Baseの記事で得ることができる: 173673と 172540
マシン信頼アカウント作成の第3の(そして推奨する)方法は、クライアントが ドメインに参加する時、必要に応じて Samba サーバーアカウントを作成する方法である。
Samba の各マシン信頼アカウントは対応するUNIXアカウントを必要とするので、
通常、 UNIXアカウントを自動作成する機能が提供されている。これには smb.conf
ファイル内に add machine script オプションを設定する必要がある。
しかし、この方法は必須ではなく、対応するUNIXアカウントを手動で作成しても構わない。
[global] |
add machine script = /usr/sbin/useradd -d /var/lib/nobody -g 100 -s /bin/false -M %u |
Microsoft Windows ワークステーションやサーバーをドメインのメンバー にする手順は Windowsのバージョンによって異なる。
ユーザーがクライアントをドメインメンバーにする時、 Windows 200x は、ドメイン内で
マシンアカウントを作成する権限を持つアカウント及びパスワードの入力を要求する。
Samba管理者アカウント(すなわち、Sambaサーバー上でroot
権限を
持つSambaアカウント)をここで入力せねばならない。通常のユーザーアカウントが入力さ
れると、この作業は失敗する(訳注:net rpc rightsでSeMachineAccountPrivilege権限を
持ったユーザーも出来るのでは?)
セキュリティのため、この管理者アカウントのパスワードは/etc/passwd
でルートユーザー用に使用されているパスワード以外のものを設定するべきである。
ドメインメンバーのマシンアカウントを作成するために使用するアカウント名は
ネットワーク管理者が任意に選択する。もしそれがroot
以外なら
smb.conf
中のパラメーター
username map = /etc/samba/smbusers
で指定するファイル名中で容易にマッピングできる。
Samba管理者アカウントのセッションキーは、マシン信頼アカウントのパスワード 設定の際、暗号化キーの機能を果たす。マシン信頼アカウントはその場でで作成 されるか、または、既に存在していれば更新される。
マシン信頼アカウントが手動作成された場合、Identification Changes メニュー画面でドメイン名を入力するが、 Create a Computer Account in the Domain チェックボックスにはチェックを入れない。こうすることでマシン がドメインに参加する際に既存のマシン信頼アカウントが使用される。
もしマシン信頼アカウントがその場で作成される場合は、Identification Changes メニュー画面でドメイン名を入力し、 Create a Computer Account in the Domain チェックボックスにチェックを入れる。この場合、上記 Windows2000用 の手順に従いドメインに参加する(プロンプトに対してSamba管理者 アカウント名を入力する)。
Joining a Sambaクライアントをドメインに参加させる方法は 次の章に記述されている。
このモードのサーバー操作は、Sambaマシンをドメインセキュリティコンテキスト のメンバーにすることを含む。またこれは定義上、全てのユーザー認証は中央で 定義された認証機構(訳注:authentication regime)で行われることを意味する。 この認証機構は NT3/4形式(旧式のドメインテクノロジー)サーバー又は Microsoft Windows 2000以降で実装されているActive Directory server(ADS) が提供する。
もちろん、認証バックエンド自体はSambaがサポートしている分散ディレクトリ 構造のサーバーなら、いずれでも構わない。LDAP(OpenLDAPベース) 、Sunの iPlanet、Novellの e-Directoryなどが使用可能である。
SambaがLDAPやその他のアイデンティティ管理、あるいは、ディレクトリ サービスを使用するように設定される場合、ユーザー及びマシン認証を継続して 実行するのはSambaである。Sambaが行う認証をLDAPサーバーが代替するわけでは ないことに注意。
ドメインメンバーサーバーのドメインマシンアカウント作成に関する詳細情報や Sambaドメインメンバーマシンがドメインに参加し完全に信頼されるようにする 方法に関しては、ドメイン管理の章を参照のこと。
下記の表に、この後この章で使用される名前を示す。
Table 6.1. 前提
Samba DMSのNetBIOS名: | SERV1 |
Windows 200x/NTドメイン名: | MIDEARTH |
ドメインのPDCのNetBIOS名: | DOMPDC |
ドメインのBDCのNetBIOS名: | DOMBDC1とDOMBDC2 |
まずsmb.conf
ファイルを編集し、Sambaが以後ドメインセキュリティを
使用するように設定しなければならない。
smb.conf
中の[global]セクション中にsecurity
行を、下記のように変更(又は追加)する:
security = domain |
もしも、パラメーターsecurity = user
が使われている
ならば、このマシンはスタンドアロンサーバーで動作するのでドメインメンバー
サーバーではないことに注意。ドメインセキュリティモードはSambaにドメイン
セキュリティコンテキスト内で動作するようにさせる。
次に、[global]
セクション中の
workgroup行を下記のように修正する:
workgroup = MIDEARTH |
これが参加するドメイン名である。
ユーザーが NT PDC で認証されるようにencrypt passwords
パラメーターをyes
に設定しなければならない。もしこの
パラメーターが特に指定されていなければ、既定値で設定されている。
このパラメーターを設定する必要はないが、もしもsmb.conf
ファイル中で指定
されたならば、必ずYes
に設定されねばならない。
最後に、[global]セクションのpassword server行 を下記のように追加(又は修正)する:
password server = DOMPDC DOMBDC1 DOMBDC2 |
これらはSambaがユーザー認証のために通信を行うプライマリ及びバックアップの ドメインコントローラーである。Sambaは各サーバーに対し、リスト順に接続するので、 複数のドメインコントローラーの間で認証負荷を分散するためには、このリストの 順番を適宜変更してもよい。
代わりに、認証に使用するドメインコントローラーのリストを smbdが自動的に決める ようにしたい場合、この行を次のように設定する:
password server = * |
この方法で、NTと全く同じメカニズムをSambaが使用するようにできる。この方法は ブロードキャストベースの名前解決を使用するか、WINS データベースの検索により 認証するドメインコントローラーを決めるか、DNSによる名前解決によりドメイン コントローラーを見つける。
root#
net rpc join -S DOMPDC -U
Administrator%password
もしも、-S DOMPDC
引数が与えられない場合、ドメイン名はsmb.conf
から入手し、PDCのNetBIOS名は、WINS検索を使うか、NetBIOSブロードキャストベースの名前
検索のどちらかで入手する。
マシンがDOMドメインに参加しようとしていて、そのドメインのPDC(ドメインのSAMデータ
ベースへの書き込み権限のある唯一のマシン)がDOMPDCなので、
-S
オプションを使用する。
Administrator%password
は、はマシンをドメインに追加する
のに必要な権限を持つアカウントのログイン名とパスワードである。これが成功すれば、
使用しているターミナルの画面に下のようなメッセージが表示される。
古いNT4式のドメイン環境使用の場合:
Joined domain DOM.
Active Directory使用の場合、ADSドメインへ参加するためのコマンドは以下の通り:
root#
net ads join -UAdministrator%password
成功すると以下の結果が表示される:
Joined SERV1 to realm MYREALM.
詳細情報については、net
のマニュアルページと
リモート管理の章を参照のこと。
この手順により、事前にPDC上でマシン信頼アカウントを作成する必要はなく、 サーバーがドメインに接続できる。
このコマンドは、マシンアカウントパスワード変更プロトコルを通して、
Sambaサーバーの新規(任意の)マシンアカウントパスワードを、smbpasswdファイルが
通常格納されているディレクトリと同じディレクトリにあるファイルに書き込む。
DMSによって必要とされる信頼アカウント情報は
/usr/local/samba/private/secrets.tdb
か
/etc/samba/secrets.tdb
ファイル中に書かれる。
このファイルはrootにより作成・所有され、root 以外のユーザーは読めない。これが、 システムのドメインレベルのセキュリティの鍵を握る部分であり、シャドウ パスワードファイル同様に慎重に扱わなければならない。
最後に、Sambaのdaemonを再起動し、クライアントがドメインセキュリティを使用開始する 準備をする。Samba デーモンの再起動方法はディストリビューションにもよるが、ほとんど の場合は次のとおりである:
root#
/etc/init.d/samba restart
現在、Samba のドメインセキュリティでは、サーバーに紐づくユーザーに対応するローカルUNIXユーザーを
作成しなければならない。このことは、もしも、ドメインユーザーDOM\fred
がドメインセキュリティのSambaサーバーに紐づく場合、UNIXファイルシステム上にそれに対応する
fred というローカル UNIXユーザーがいなければならないことを意味する。これは以前のSambaの
セキュリティモードであるsecurity = serverと似ているが、
このモードでは、Windows 95又はWindows 98サーバーと同じように、 Sambaが認証リクエストを
Windows NT サーバーに回送していた。
UNIX の UID 及び GID を自動的に Windows NT ドメインユーザー及びグループへ割り当てる システムについての情報はWinbind: ドメインアカウントの使用 を参照のこと。
ドメインレベルのセキュリティの利点は、NT サーバーと全く同じように、ドメインレベルセキュリティ における認証が、認証されたRPC チャンネルを通ることである。これは、Sambaサーバーが NT サーバーと 全く同じやり方でドメインの信頼関係に参加できることを意味する(すなわち、Sambaサーバーをリソース ドメインに追加し、リソースドメインPDC からアカウントドメイン PDC に認証を渡してもらうことができる)。
さらに、security = server(訳注:サーバーレベルのセキュリティ) を使う場合、サーバー上のすべてのSambaデーモンは、起動している限り認証サーバーと接続し続けなければ ならない。これはMicrosoft NTサーバーの接続リソースを使い果たし、利用可能な接続がなくなることに なりかねない。それに対しsecurity = domain (訳注:ドメインレベルのセキュリティ)の場合は、Sambaデーモンはユーザー認証に必要な時のみPDC/BDCに 接続し、その後接続を切断する。これにより PDC の接続リソースを節約することができる。
最後に、NT サーバーと同じように PDC 認証を行うということは、認証の返答の一部として、ユーザー SIDや ユーザーが属する NTグループなどのユーザー識別情報を、Samba サーバーが受け取ることを意味する。
この文書の内容の大半は、ウェブマガジン LinuxWorldの記事 http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html Doing the NIS/NT Sambaとして最初に発表された(訳注:リンク切れ)。
これは、Windows 200x KDC に対し Kerberos認証を行うSamba-3の設定方法の概略である。 Kerberosの知識を有することを前提としている。
最低以下の3つのオプションをsmb.conf
で使用しなければならない:
realm = your.kerberos.REALM |
security = ADS |
# もしも存在するときのみ、以下のパラメーターを指定する必要がある。 |
# もしも存在しないときの既定値はYesである。 |
encrypt passwords = yes |
Samba がレルム名を使用して適切な ADS サーバーを正確に識別できない場合、
smb.conf
中のpassword serverオプションを使用する:
password server = your.kerberos.server |
ADSドメインコントローラーを識別できない最も共通的な理由は、ADS基盤のDNS要求条件
に関係なくUNIXシステム上でいくつかのDNSサーバーを保守しているサイトの問題である。
password server
を使って、優先するADSドメインコントローラー
を指定することは問題ない。
smbpasswdファイルは必要でなく、古いクライアントは あたかもsecurity = domainのように 認証され、何の害もなく、ドメインに入らないローカルユーザーを持つことが できる。
MIT 及び Heimdal Kerberosでは、/etc/krb5.conf
の
設定は必要なく、時に害となることがある。
Microsoft ADSは、DNSの_kerberos._tcp.REALM.NAME
に、
レルム内の各KDCのSRVレコードを、自動的に作成する。 これは、Active Directory
ドメインを作成するために使われるインストールと設定プロセスの一部である。
KDCはKerberosのキー配信センタであり、Microsoft Active Directory基盤の
不可欠な部分として構成されている。
UNIXシステムは、Windows2000 KDCにで認証を行うために、kinitとDES-CBC-MD5 又はDES-CBC-CRCという種類の暗号手法を使える。Windows 2000 ADSのkerberos 相互運用性に関連する詳細情報は、 Interoperability というガイドを参照のこと。もう1つの、とても有用な、Kerberosの相互運用性に関する 一般的な情報として参照できる文書は、 RFC1510 である。このRFCはKerberosの操作についてのたくさんの不可思議な背景について説明している。
MITとHeimdalでは、最新のKRB5ライブラリがSRVレコードをチェックするように
既定値で設定されていて、従って、自動的にKDCを見つける。さらに、
krb5.conf
は、たとえ2つ以上あったとしても単一のKDCの
指定のみ許可する。DNSルックアップを使用することによりKRB5ライブラリは使用
可能な任意のKDCを使用できる。
手動でkrb5.conf
を設定する場合の最小限の設定は次のとおり:
[libdefaults] default_realm = YOUR.KERBEROS.REALM [realms] YOUR.KERBEROS.REALM = { kdc = your.kerberos.server } [domain_realms] .kerberos.server = YOUR.KERBEROS.REALM
Heimdal のバージョン 0.6 以前を使用する場合は次のように設定する:
[libdefaults] default_realm = YOUR.KERBEROS.REALM default_etypes = des-cbc-crc des-cbc-md5 default_etypes_des = des-cbc-crc des-cbc-md5 [realms] YOUR.KERBEROS.REALM = { kdc = your.kerberos.server } [domain_realms] .kerberos.server = YOUR.KERBEROS.REALM
kinit
を実行して設定をテストし、パスワードが Windows 2000 KDC に認証されることを確認
する。
USERNAME
@REALM
Heimdal 0.6.x 以前のバージョンでは、ADSで新規に作成されたアカウントであるか、
移行後にパスワードが変更されたアカウントであるか、インストール後に
Administrator
であれば使用できる。現行、Windows 2003 KDCは
Heimdal のバージョン 0.6 以降のリリース(かつkrb5.conf内にetypesの既定値の設定が
ないもの)とのみ使用できる。残念ながらこの領域はいまだに流動的な状態である。
レルムは大文字でなければ、 “Cannot find KDC for requested realm while getting initial credentials (最初の認証情報取得時にリクエストされたレルムの KDC を見つけられない)” というエラーが表示される(Kerberos は大文字・小文字を区別する)。
2つのサーバーは時間の同期を取らなければならない。もし時間差が5分以上になると メッセージ “kinit(v5): Clock skew too great while getting initial credentials (kinit(v5): 最初の認証情報取得時にクロックスキューが過大)” が表示される。
Kerberos プロトコルではクロックスキューの限界値を設定できる。既定値は5分である。
更に、使用するKDCのIP アドレスによる逆引きDNS検索をできるようにしなければならない。 また、この逆引きDNS検索がマッピングする先の名前はKDCのNetBIOS名(すなわち、ドメイン に紐づかないホスト名)またはレルムが後に付くNetBIOS名のどちらでもよい。
以上を確実に行うための最も簡単な方法は、使用するKDCのIPアドレスをマッピングする
/etc/hosts
のエントリを、KDCのNetBIOS名に追加することである。
もし正しくなければ、レルムに参加しようとするとlocal error
が発生する。
smbclient中でのKerberos のサポートのみが必要な場合は、次の項は飛ばして直接 smbclientでのテストに進むこと。 コンピュータアカウントの作成と サーバー設定のテストは、 smbdとwinbinddでKerberosのサポートをしたい場合にのみ必要である。
Samba のプライベートディレクトリに書き込み権限があるユーザー(通常はroot)として以下を実行する:
root#
net ads join -U Administrator%password
管理者アカウントは、ADSドメインにマシンを追加することを許可されているADSドメインセキュリティ の設定中で指定された任意のアカウントでも良い。それはもちろん、Administrator以外のアカウント を使うことは良いアイデアである。UNIX/Linuxシステム上では、このコマンドはUID=0(root)である アカウントによって実行されねばならない。
複雑な組織内でWindowsクライアントをADSドメインのメンバーにする場合、特定の組織単位内で マシンアカウントを作成しても良い。Samba-3では次の構文でこれを実現できる:
root#
kinit Administrator@your.kerberos.REALM
root#
net ads join createcomputer="organizational_unit"
ADS管理者は"organizational_unit"パラメーターに指定すべきものを助言することも可能である。
例をあげると、ある組織ディレクトリ“Computers/BusinessUnit/Department,” の配下の“Servers”というコンテナにマシン信頼アカウントを作成したい場合 は以下のようになる:
root#
net ads join "Computers/BusinessUnit/Department/Servers"
このコマンドは、コンテナComputers/BusinessUnit/Department/Servers
中に、Sambaサーバーのマシン信頼アカウントを置く。コンテナはこのコマンドを実行する前に
ADS ディレクトリ中に存在しなければならない。バックスラッシュはOU名とその他の文字に
対するエスケープ文字の両方として有効な文字のため、普通のスラッシュを使わなければ
ならないことに注意。もしもOU名にバックスラッシュを使う必要があるならば、シェルによる
解釈と、LDAPによる解釈を考慮して4重にする必要がある。
Kerberosライブラリとヘッダーファイルのインストール後に、Samba を再設定(config.cache を削除) して、リコンパイルする(make clean all install)。
kinit
を使ってドメインにログインする必要がある。
USERNAME
@REALM
USERNAME
はマシンをドメインへ追加する権限を持つユーザーでなければならない。
/etc/krb5.conf
システムにインストールされているKerberosの
タイプとバージョンに対して適切に設定されているか確認する。
参加に成功したら、Active DirectoryにSambaサーバーのNetBIOS名の付いた 新規のコンピュータアカウントが表示される(ユーザーとコンピュータ配下の “コンピュータ”フォルダー中)。
Windows 2000 クライアントでは、net use * \\server\share
を試してみること。パスワードを知らないでもKerberos にログインできるはずである。
もしも失敗したら、klist tickets
を実行すること。
サーバー用のチケットを取得できたか?それには暗号タイプ DES-CBC-MD5 があるか?
SambaはUNIXユーザー及びグループ(それぞれUIDとGIDで識別される)をWindowsユーザー及び
グループ(SIDで識別される)にマッピングする。これらのマッピングは Sambaの
idmap
サブシステムが行う。
これらのマッピングをSambaドメインメンバー間で共有することは、 名前からIDへのマッピングが全マシンで同一になるので便利である。 特に、CIFSとNFSの両方でファイルを共有する場合に有用である。
LDAP ldap idmap suffix
を使う場合、以下のように設定する:
ldap idmap suffix = ou=Idmap |
詳細情報については smb.conf
マニュアルページのldap idmap suffix
パラメーターのエントリを参照のこと。
ldap admin dnも設定することと、secrets.tdb
中にLDAP管理用パスワードを設定するのを忘れないこと。これには下記を使用する:
root#
smbpasswd -w ldap-admin-password
ldap-admin-password
の部分は、システムで使うLDAPサーバー管理用パスワードで
置き換えること。
ドメインメンバーのマシンアカウントの追加/削除/再追加の手順の中には、不注意により 陥りやすい多くの落とし穴や間違いを招きかねない多くの“事細かな”こと がある。興味深いことにSambaメーリングリストの購読者の中には、マシンアカウントの 追加を繰り返し失敗し、最終的にMicrosoft Windows をマシンに“再インストール” しなければならないという結論を出す人がよくいる。しかし、実際はこのような種類の問題で 再インストールが必要になることはめったにない。正しい解決法は単純である場合が多く、 Microsoft Windowsのネットワーク機能を理解していれば容易に解決できる。
“ Windowsワークステーションを再インストールした。元々のドメインマシンアカウントが削除され その直後に再度追加された。同じマシン名を使用するとワークステーションはドメインに参加 できない。マシンの追加に失敗する際に、マシンはネットワーク上に存在していないにもかか わらず、マシンが既に存在するというメッセージが表示される。なぜこのように失敗するのか? ”
前の名前がまだNetBIOS 名キャッシュに残っているためである。マシンアカウントが削除されると、
同じ名前のマシンをドメインメンバーとして再度追加できるようになるには、まず、その名前が
期限切れにならなければならない。最もよい方法は、古いアカウントを削除し、新しい名前で
マシンを追加することである。そのほかに、Windows上のクライアントから以下のnbtstat
コマンドを使って、名前キャッシュにある現在のデータをフラッシュし、再ロードする。
C:\>
nbtstat -R
“ Windows200xもしくはXP ProfessionalマシンをSamba PDCドメインに追加しようとすると失敗する。 エラーメッセージは 今回はネットワークの問題によりマシンを追加できませんでした。後ほどやり直して下さい。 である(訳注:実際に表示されるメッセージとは違います)。なぜか?”
smb.conf
ファイル中にadd machine scriptがあることを確認する。
もしも存在していないならば、OSプラットフォームに適したスクリプトを追加する。もしも、
スクリプトがすでに定義されているならば、その動作をデバッグする必要がある。
smb.conf
ファイル中のlog levelの値を10まで増やし、
ドメインへの参加を試行してみる。そのログをチェックし、どの動作が失敗しているか突き止める。
可能性のある原因:
add machine scriptはSamba バックエンドデータベースでは、 マシンアカウントを作成しない。Sambaバックエンドデータベースアカウントがマッピング される先のUNIXシステムアカウントを作成するためにのみあるものである。
Windows 2003はSMB署名を必要とする。クライアント側のSMB署名はSamba-3.0で 実現されている。Windows 2003サーバーと通信する際には client use spnego = yesに設定する。 この機能は、クライアントは単純にそれ自身とサーバーと両方がサポートする プロトコルをネゴシエートするので、Windows 2003が持つより高度なセキュリティ 機能をサポートしない他のWindowsクライアントとインタフェースを取れない。 これは、SMB/CIFSプロトコル中で構築されているよく知られたフォールバック 機能である。
スタンドアロンサーバーは、ネットワーク上での独立したドメインコントローラーである。 それらはドメインメンバーではなく、ワークグループサーバーのように機能する。 多くの場合、スタンドアロンサーバーは、提供されたデータが容易にすべての利用者 からアクセス可能という意図で、最低限のセキュリティ制御で設定されている サーバーである。
スタンドアロンサーバーは、必要性によって、セキュアにも非セキュアにもできる。 単純あるいは複雑な設定を取ることが出来る。上記のように、ドメインセキュリティ について、過大な説明にもかかわらず、多くは普通のインストールのままである。
もしも、サーバーに必要とされるものがすべて読み込み専用ファイルか、プリンター のみならば、複雑な設定をするのは意味をなさない。たとえば、設計事務所 が古い設計図と設計標準を格納しておく必要があるとする。すべての文書が 変更されないままでいることが法律的に重要なので、誰もサーバーにファイルを 書き込めない。シェアモードのリードオンリスタンドアロンサーバーは理想的 な解決方法である。
単純さを正当化するもう1つの状態は、一つの中央サーバーから待ち行列に入れられる 多くのプリンターを持っているオフィスである。全員がプリンターに印刷出来る要求が あるが、アクセス制御の必要がなく、プリンターサーバーにはファイルがない場合である。 繰り返すと、シェアモードスタンドアロンサーバーはとても優れた解決方法を提供する。
standalone serverという言葉は、ローカルな認証とその上で 有効なすべてのリソースのアクセスを制御する機能を提供するという意味である。 一般的に、これは、ローカルユーザーデータベースがあると言うことを意味する。 もう少し技術的な言葉で言うと、これは、マシン上のリソースは、 shareモードかuserモードのいずれか が有効であるということである。
ユーザーアカウントを作成するため以外に特別な操作は必要ない。スタンドアロンサーバー はネットワークログオンサービスを提供しない。これは、このサーバーを使うマシンは これに対するドメインログオンを実行しないことを意味する。ワークステーションが 使うどんなログオン機能も、このマシンからは独立している。しかし、使用する ログオン名がローカルで持っているユーザー名をスタンドアロンサーバー上でローカルに 変換(マップ)するために、任意のネットワークユーザーを一致させることは必要である。 このことを実行するためにはいくつかの方法がある。
Sambaはスタンドアロンサーバーの定義中で少しだけ区別を曖昧にするのに 役立つ。これは、SMBプロトコルの視点から、Sambaサーバーがドメイン セキュリティコンテキストのメンバーでないとしても、認証データベース がローカルかリモートサーバー上にあるという理由である。
UNIXユーザーデータベースを操作するPAMとネームサービススイッチ(NSS)を使って
(PAMに付いての節を参照)、認証のソースは
別のサーバー上にあってもよい。これを認証サーバーと呼ぶ傾向がある。これは、
SambaサーバーはローカルのUNIX/Linuxシステムパスワードデータベース
(/etc/passwd
か/etc/shadow
)か、
ローカルのsmbpasswdファイルか、LDAPバックエンドか、認証のために、
PAMとWinbind経由で他のCIFS/SMBサーバーを使っても良いことを意味する。
参照用文書サーバーの例と センタ印刷サーバーは単純さに ヒントを得てデザインされた。それは高度な創造性を試みることと、 サーバーとネットワーク設計においてとても複雑であることを説明することは とても簡単である。
誰でもアクセスできる読み込み専用データサーバーの設定はとても単純である。既定値
では、すべての共有は、smb.conf
ファイルに何か書かれるまではリードオンリで
ある。
参照用文書サーバーの例
はこれを行うためのsmb.conf
ファイルである。すべての参照用文書はディレクトリ
/export
に格納されていて、文書はnobody以外のユーザーによって
所有されていることを仮定する。ホームディレクトリは共有されず、UNIXシステム
データベース/etc/passwd
中にはユーザーはいない。これは
管理者にとって単純なシステムである。
もう少し準備に時間があれば、もう少し簡単にできた。 | ||
--Mark Twain |
この例中で、マシン名はGANDALFに設定 され、ワークグループはローカルワークグループ(MIDEARTH)の名前に設定され、 ユーザーがなじみのあるシステムと一緒に表示される。必要とされる唯一のパスワードバックエンド は、既定値の非制限アカウント名として使われることを許可する“guest” バックエンドである。このネットワーク上でWINSサーバーがあるならば、もちろんそれを使う。
米国空軍連隊長が言った有名なことは: A US Air Force Colonel was renowned for saying: “最善は善の的(Better is the enemy of good enough!)”。 専門的に完全な解決を避けることと同様、複雑さを避けることに対して、しばしば健全な理由が 存在する。不幸にも、トラブルがないことを保持するのにちょうど十分な術を、多くの ネットワーク管理者は引き続き覚える必要がある。
単純な印刷サーバーの設定は、システム上のすべての正しいツールがあるならば簡単である。
前提条件
印刷サーバーは管理不要でなければならない。
印刷サーバー印刷の、スプールと処理をするシステムはCUPSである。 (詳細情報はCUPS印刷システムを参照のこと)。
印刷サーバーはネットワークプリンターのみ処理を行う。ネットワーク管理者は プリンターをサポートするためにCUPS環境を正しく設定している。
すべてのワークステーションはPostScriptドライバーを使う。選択したプリンター ドライバーはApple Color LaserWriterのためのWindows OS用のものを選択する。
この例では、印刷サーバーは入力したすべての印刷ジョブを、Sambaによって、CUPS
印刷プロセッサに向けて送られたジョブが実行可能になるまで
/var/spool/samba
にスプールする。すべての入力された
接続は匿名(guest)ユーザーなので、匿名印刷を有効にするために、2つ設定が必要である。
匿名印刷を有効にする
UNIX/Linuxシステムはguest
アカウントを持たねば
ならない。この既定値は、通常nobody
である。
使用するバージョンで使っている正しい名前を探すためには、以下を実行する:
$
testparm -s -v | grep "guest account"
このアカウントはシステムのパスワードデータベース
(/etc/passwd
)に存在するようにしておかねばならない。
このアカウントに対してパスワードを設定するか、UNIXでの使用からロックすることは
良い考えである。ゲストアカウントがpcguest
であると仮定した時、
以下を実行することでロックが出来る:
root#
passwd -l pcguest
正確なコマンドは使用するUNIX/Linuxディストリビューションによって異なる。
Sambaがファイルをスプールするディレクトリはゲストアカウントに対して 書き込み許可を持たねばならない。以下のコマンド操作で、このディレクトリ が使えるようにする:
root#
mkdir /var/spool/samba
root#
chown nobody.nobody /var/spool/samba
root#
chmod a+rwt /var/spool/samba
smb.conf
ファイルの内容は匿名印刷の例にある。
CUPSが有効なシステム上で、CUPSプリントフィルタ経由の中間処理なしで生データを
直接プリンターに送る機能がある。このモードの操作が要求される場合、raw印刷デバイス
の設定が必要である。また、/etc/mime.conv
と
/etc/mime.types
ファイル中にraw mime ハンドラーを有効にする
設定も必要である。CUPS印刷サポート、
application/octet-streamで明示的にraw印刷を有効にする
を参照のこと。
匿名印刷の例中では、CUPSライブラリAPI経由で
直接印刷のためにCUPSを使用する。これは、すべてのプリンターはprintcapファイルを設定する
必要なしにWindowsユーザーから見えるようになるという意味である。もしも、プリンターの
サブセットのみか、特別な種類のプリンター(たとえばPDFフィルタ)を見せる必要がある
ならば、printcap name = cups
を
printcap name = /etc/samba/myprintcap
に置き換えても良い。
この場合、指定されたファイルはWindowsネットワークユーザーに見せるべきプリンター名の
一覧を含む必要がある。
Table of Contents
時折、Microsoft WindowsクライアントがSambaサーバーに正しく相互運用を行うことが 難しいと、ネットワーク管理者が報告している。Microsoft Windows NT4か200xサーバー を使うときのように、Microsoft Windowsネットワーククライアントが正しく設定する ための正しい方法という事実を何人かが受け入れられないように見える。それでも、 詳細なWindowsクライアント設定の手順を提供するという継続的な必要性がある。
この章の目的は、最も共通的な重要な設定場面での設定について、Microsoft Windows クライアントの設定をGUIで説明することである。十分に経験のあるネットワーク管理者 は、この章の詳細については興味がないだろう。
この章では、現在一般的に使われているプラットフォームのためのネットワーク メンバーシップと同様に、TCP/IPプロトコルについて説明する。それは以下の通り:
Microsoft Windows XP Professional
Windows 2000 Professional
Windows Millennium edition (Me)
大工さんは家を建てるときには基礎がしっかりしている上で建築することを保証しな ければならない(訳注:やや意訳)。TCP/IPベースのネットワークシステムの構築者に とってもこれは真である。ネットワーク基盤設定の問題はそれが解決するまで、 すべてのネットワークユーザーを悩ませる。
Microsoft Windowsワークステーションとサーバーは固定IPアドレスかDHCPのどちらでも 設定できる。以下での例ではDHCPを使い、固定IP設定に影響される場面においては、 参照先への参照のみを行っている。
特定の設定画面に到達するためにショートカットや短縮されたキーストロークを 使うことが可能である。この章でのすべての例のベースのために、 ボタンを使うことを決めごととした。
Windows XP TCP/IP 設定パネルへは2つのパスがある。どちらか好きな方を 選べばよい:
とクリック。
もう1つの方法は click をクリックし、 を右クリックし、 をクリックする。
以下の手順はWindows XP ProfessionalのTCP/IP設定手続きのステップである:
いくつかのインストールにおいて、インタフェースは と その他では と呼ばれる。ここでの例においては と呼ばれる。 と右クリックする。 “Network Bridgeの設定”を参照。
Network Bridge Configurationの設定か、ローカルエリア接続の設定で、TCP/IPプロトコル 設定のためにパネルが使われる。 というボックス中で、 をクリックし、次に、 をクリックする。
既定値の設定は、DHCPが有効な動作である。 (すなわち、“IPアドレスを自動的に取得する”)。 “インターネット プロトコル(TCP/IP)のプロパティ”を参照。
多くのネットワーク管理者は、すべてのクライアントTCP/IPプロトコルスタックの 設定においてDHCPを使う設定をしたいと思っている(Windowsクライアントをサポート するための ISC DHCPサーバーの設定方法についての情報は、 DNSとDHCP設定ガイドと、DHCPサーバー を参照)。
もしも、固定IPを使う必要があるならば、“次のIPアドレスを使う”を クリックし、IPアドレス、サブネットマスク、デフォルトゲートウェイをそれぞれの ボックスに入力する。
TCP/IP設定にある をクリックする。このインタフェースに 対する追加のIPアドレスを作成することが可能になるパネルが開く。 追加のIPアドレスに対する技術的な名前はIPエイリアスであり、 さらに、追加のデフォルトゲートウェイ(ルータ)を設定することもできる。ほとんどの場合、 DHCPが使われていると、追加の設定は必要ない。このパネルの外観は、 “ネットワークの詳細設定”を参照。
タブをクリックし、DNSサーバーの設定を追加する。 例題のシステムでは、手動でのDNS設定を使っている。変更が終了したなら、 をクリックして変更を確定する。 “DNSの設定”を参照。
タブをクリックして、手動でWINSサーバーの 設定を追加する。この手順は、例題のシステムで、手動でWINSサーバーの設定 を行うことを行っている。変更が終了したならば、 をクリックして変更を確定する。“WINS Configuration”を参照。
TCP/IP設定パネルを表示させるためには2つの方法がある。以下のどちらを使っても良い:
をクリック(訳注:正しい訳か未確認)。
その代わりに、 をクリックし、 を右クリックし、 を選択する。
以下の手順はWindows XP Professional TCP/IP設定の手順である:
ローカル エリア接続のプロパティはTCP/IPプロトコル設定を設定するのに使われる。 中の をクリックし、次に ボタンをクリックする。
既定値はDHCP有効な設定である(すなわち“IP アドレスを自動的に取得する”)。 “インターネット プロトコル (TCP/IP)のプロパティ”を参照。
ネットワーク管理者の多くは、すべてのクライアントのTCP/IPプロトコルスタック設定 をDHCPを使うように設定したいと思っている(ISC DHCPサーバーをWindowsクライアントを サポートするように設定する方法についての情報は“DHCPサーバー” を参照のこと)。
もしも、固定IPアドレスを使いたいならば、“次の IP アドレスを使う”をクリックし、 IPアドレスとサブネットマスクとデフォルトゲートウェイのIPアドレスを所定の位置に入力する。 この例では、すべてのネットワーククライアントはDHCPで設定されていることを仮定している。
“TCP/IP 詳細設定”を参照。
ボタンをクリックして、TCP/IP詳細設定を実行する。
DNSサーバー設定のために タブをクリックする。 例題システムでは、手動でのDNS設定を使っている。変更が完了したならば、 をクリックして変更を確定する。 “DNS設定”を参照。
WINSサーバーエントリ設定のために タブをクリックする。 このステップは、例題システムにおいて、手動でのWINS設定を使うことを示している。 変更が完了したならば、 をクリックして変更を確定する。 “WINS設定”を参照。
Windows Millennium edition (Me)でTCP/IP設定パネルを呼び出すには2つのパスがある。以下のどちらかを実行する:
をクリックする。
別の方法として、 をクリックし、 を右クリックし、 を選択する。
以下の手順は、Windows MeのTCP/IP設定手順である:
というタイトルのボックス中で、 をクリックし、次に ボタンをクリックする。 “Windows Me ネットワーク設定パネル”を参照。
ネットワーク管理者の多くは、すべてのクライアントのTCP/IPプロトコルスタック設定 をDHCPを使うように設定したいと思っている(ISC DHCPサーバーをWindowsクライアントを サポートするように設定する方法についての情報は“DHCPサーバー”と を参照のこと)。Windows Me ワークステーションでの既定値の設定はDHCP有効である (すなわち、 が有効)。 “IPアドレス”を参照。
もしも固定IPアドレスの指定が必要ならば、 をクリックし、 IPアドレス、トサブネットマスクをボックス内に入力する。この例では、すべてのネットワーククライアントは DHCPを使うように設定されていると仮定している。
必要に応じてDNSサーバー設定追加のために タブをクリックする。 WINSサーバー設定追加のために タブをクリックする。 タブでは、追加のゲートウェイ(ルータアドレス)を、 ネットワークインタフェース設定追加できる。DHCPを使うほとんどの場合では、 手動でこれらの設定を作成することは不要である。
以下は、WINSを手動で設定する例である。“DNS設定”を参照。 変更が終わったら、 をクリックして変更を確定する。
これは、手動でWINS設定したシステムの例である。これができよう出来るような状況は、 複数のWindowsワークグループまたはドメインの設定を提供する単一のDHCPサーバーがある ネットワークである。“WINS設定”を参照。
Microsoft Windows NT/200x/XP Professional platformsはドメインセキュリティに参加できる。 この節では、Windows 200x/XP Professionalマシンをドメインセキュリティ環境のメンバーにする 手順を説明する。この手続きは、Windows NT4/200xによって制御されるドメインへ参加する時 とSambaPDCでは同一であることに注意されたい。
をクリック。
を右クリックし、次に を選択。
パネルのオープンは、コントロールパネル上の をクリックしても 同様に行える。“全般”を参照。
タブをクリックする。 このパネルでは、 、 と または が表示されている。
ボタンをクリックすると、設定ウィザードが起動する。Samba-3では これを使ってはならない。コンピュータ名やドメインからの離脱を行いたいならば、 ボタンを使う。“コンピュータ名パネル”を参照のこと。
“コンピュータ名の変更パネル”を参照。
をクリックする。このパネルでは例題のシステム(TEMPTATION)がWORKGROUPという ワークグループであることを示している。 MIDEARTHというドメインにこれから参加する。
このパネルでは、例題のシステム(TEMPTATION)がMIDEARTHと呼ばれるドメインに参加することを示している。 “コンピュータ名の変更パネル ドメイン MIDEARTH”を参照。
ボタンをクリックする。マシンをドメインに参加させる権利を持つドメイン管理者 アカウントの認証(ユーザー名とアカウント)を入力するためのダイアログボックスが現れる。
Samba-3サーバーの“root”とパスワードを入力する。“コンピュータ名の変更 ユーザー名とパスワードパネル”を参照。
をクリックする。
“MIDEARTHドメインへようこそ”ダイアログボックスが現れる。この時点でマシンを再起動する必要がある。 これでドメインへの参加が完了する。
Windows 9x/Meマシンがドメインに参加できるということを言う時に、とても一般的に用いられる慣例に従う。 実際には、これらのプラットフォームはLanManagerネットワークログオンプロトコルのみを使うことが出来る。
アイコンを右クリックする。
ネットワーク設定パネルには、変更可能なすべての共通なネットワーク設定がある。 “ネットワークパネル”を参照。
クライアント用Microsoftネットワークプロパティパネルではネットワークログオンの設定をするための 所である。“クライアント用Microsoftネットワークプロパティパネル”を参照。
ボタンをクリックする。これは、設定すべきワークグループ (ドメイン)名とマシン名(コンピュータ名)がある所である。“識別パネル”を参照。
次に ボタンをクリックする。もしもドメインユーザーとグループ アカウントを使って共有アクセスパーミッションを割り当てたいならば、このパネル中にある を有効にする必要がある。 “アクセス制御パネル”を参照。
最もよくあるWindowsネットワークシステムに悪影響を及ぼすエラーは下記の通り:
不正なIPアドレス。
不正又は矛盾したネットマスク。
不正なルータアドレス。
不正なDNSサーバーアドレス。
不正なWINSサーバーアドレス。
これについて注意するネットワークスコープ設定を使う!
Windows NT/200x/XP ProfessionalクライアントがSamba制御下のドメインに参加できない最も一般的な理由は 以下の通り:
smb.conf
で正しいadd machine script設定をしていない
“root”がパスワードバックエンドデータベースにない。
ドメインに参加するときに“root”以外のユーザーアカウントを代わりにに使っている。
ワークステーションからサーバーに対する接続が切れている。
クライアント又はSambaサーバーにファイアウォールかフィルタの設定がなされている。
Sambaにはいくつかの必要/不必要な機能が用意されている。以下の 節では、Sambaにおける特定の機能について個別に説明している。
Table of Contents
cupsomatic/foomatic
の役割mime.convs
cupsaddsmb
用のsmb.conf
の準備*.tdb
ファイルcupsaddsmb
が、新しくインストールしたプリンターで動かない/var/spool/samba/
のアクセス許可が、再起動後毎回リセットされるTable of Contents
Sambaをアップデートまたはアップグレードする前に、この章を注意深く読んでほしい。 ここにはとても重大か、とても重要な情報のみが書いてある。包括的な変更記録とガイ ダンス情報は Sambaのアップデートとアップグレード の章にある。
以下の記述は、特にSamba 3.0.23からSamba 3.0.25c(あるいはより最新のSamba 3.0.25の更新版) に関連する。Sambaは常に変化しているプロジェクトである。3.0.xシリーズ中での変更点は、 この文書中で記述されている。 Upgrading from Samba-2.x to Samba-3.0.25 を参照のこと。
時々、HOWTO文書の、新しい、あるいは変更された機能の影響を反映するために更新すべき部分を 指示するのが難しいことがある。あるいは別の時点では、この文書を再構成することが必要で あることが明白になる。
近年では、Samba のユーザーも Samba Wiki 構築の推進に加わった。新しく作成される Samba ドキュメントは、すべてここに集約 される予定である。Wikiは規模の大きなコミュニティからの投稿に適していて、より いっそう最新情報を提供できることを期待している。そのすばらしい夢が実現して、 十分な価値が出てくるまでは、このHOWTO文書を維持管理することは必要である。 この章では、このHOWTO文書の主要部分が再構成されるか変更される時点までの間 での主要な変更点を文書化する。
この章は、Samba 3.0.23リリースでHOTWOに加わった。ここにはSambaソースコードリリース
一式中に含まれるWHATSNEW.txt
ファイル中で提供されているたくさんの
注意点を含んでいる。
マップされていないユーザーとグループアカウントのみに影響する変更点はここで文書化されている。
ユーザーとグループに対する内部管理ルーチンは割り当てられた相対識別子(RID)
の重複を防ぐために書き直された。過去では、net groupmap
コマンド
又はnet rpc vampire
コマンドで
net rpc vampire
を実行してWindowsドメインをSambaドメインにマイグレートすることによって、
手動でUnixグループにマッピングするときに問題が発生する可能性があった。
マップされていないユーザーは、今回からS-1-22-1
ドメイン中の
SIDが割り当てられ、マップされていないグループはS-1-22-2
ドメイン
中のSIDを割り当てられる。以前はSambaサーバー上のSAM内のRIDを割り当てていた。
ドメインコントローラーにとって、これは、メンバーサーバーかスタンドアロンサーバー上のような
ドメインSIDの権限の配下にあり、これはローカルSAM(net getlocalsid
マニュアルページを参照)の権限下にあった。
結果は、アップグレードされたSambaドメインコントローラー上の、あるマップされていない ユーザー又はグループは新しいSIDを割り当てられることになる。Windowsセキュリティ 記述子中に名前というかSIDが格納されるので、これは、そのユーザーが たとえば、Sambaファイルサーバーからローカルの WindowsクライアントNTFSパーティションにファイルがコピーされた場合、もはやリソースに アクセスできないという現象を引き起こす。Sambaサーバー上自身で格納された任意のファイル は、UNIXがUNIXのGIDを格納し、権限の検査にSIDを使わないために引き続きアクセスできる。
変更を図示するのに例題が役立つ:
developersという名前のグループがありそのUNIX GIDが782だと
する。この場合、このグループはSambaのグループマップテーブル中には存在しない。
このグループがACLエディター中に現れることは全く通常通りである。Samba-3.0.23より
前では、グループSIDは
S-1-5-21-647511796-4126122067-3123570092-2565
として
表示される。
Samba-3.0.23のリリースから、グループSIDはS-1-22-2-782
のよう
に表示されるようになった。任意の、Windows NTFSパーティション上に格納されるファイルに付
随するセキュリティ記述子は、ユーザーが
S-1-5-21-647511796-4126122067-3123570092-2565
グループ
のメンバーでない場合、グループパーミッションベースのアクセスを許可されない。
このグループSIDがS-1-22-2-782
で、ユーザートークン中に
表示されないという理由で、たとえ両方のSIDが同じUNIXグループを参照する
という観点においても、Windowsは認証に失敗する。
Samba 3.0.23より前での回避方法は、グループdevelopers
がS-1-5-21-647511796-4126122067-3123570092-2565
という
SIDを示すグループマップエントリを手動で作成することである。Samba-3.0.23
のリリースから、この回避方法は不要になった。
Samba 3.0.xシリーズの3.0.23より前のリリースでは、
Domain Admins, Domain Users, Domain Guests
というWindows
ドメイングループに対するグループマッピングは自動的に作成された。Samba-3.0.23
から、これらのマッピングはSamba管理者によって作成されなければならないように
なった。これが失敗すると、正しい認証と、有効なドメインユーザーの認識に失敗する
結果となる。これが起きた場合、ユーザーはWindowsクライアントにログオンできなくなる。
グループマッピングは、SambaサーバーがPDC/BDCとして動作している時にのみ重要である。 スタンドアロンサーバーはグループマッピングを必要としない。
以下のマッピングが必要である:
Table 9.1. 基本的なドメイングループのマッピング
Domain Group | RID | UNIXグループ例 |
---|---|---|
Domain Admins | 512 | root |
Domain Users | 513 | users |
Domain Guests | 514 | nobody |
POSIX(UNIX)グループがLDAP内に格納される場合、それぞれ
domadmins, domusers,domguests
と指定すると
便利である(訳注:やや意訳です)。
グループマッピングに関するさらなる情報は グループマッピング: Microsoft Windows と UNIXを参照のこと。
もはやpassdb backendパラメーターは、複数のpassdbバックエンドを 連続して設定できない。SQLとXML passdbバックエンドもSamba-3.0.23のリリースから取り除 かれた。外部のSQL passdb サポートについてのより詳細な情報は pdbsqlページを参照のこと。
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 not
without 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環境のどちらかで自動的に生成されないという理由で、Samba DMS用に適切なDNSエントリを手動で作成する必要がある。
時折、Microsoft DNSサーバーの代わりにUNIXベースのDDNSサーバーを使いたいというUNIXネッ トワーク管理者の要望を聞くことがある。これが誰かにとって都合がよい間、Microsoft Windows 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
; <lt;>> DiG 9.2.2 <lt;>> @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.16
noldor.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 will have 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
で示されるオプションを設定する:
必要であれば、DMBはWINSサーバーと同じマシンでも良い。
次に、ワークグループに対する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文字(名前タイプ情報を含め)である。
WINSは登録された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 = <name>オプションを
同時に設定すると、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 SMB browsing has been problematic for some Samba users, hence this document.
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 LMBs will continue to occur, but this should remain a steady-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)、一般的に反応がとても遅くなる。
Table of Contents
以前のSamba3リリースでは複数のアカウント情報バックエンドを同時に動作させることが できた。この機能はSamba3.0.23からなくなった。Samba3.0.23からは、passdbバックエンド は1つのみ指定できる。
3つのpassdbバックエンドがSambaチームで完全なメンテナンスが行われており、それは以下である:
smbpasswd
(旧式)、tdbsam
(tdbベースのバイナリファイル
形式)とldapsam
(LDAP)。もちろん、ldapsam
バックエンド
のみが、POSIX(UNIX)とSambaのユーザーとグループアカウント情報を単一のリポジトリに格納できる。
smbpasswd
とtdbsam
バックエンドはSambaユーザー
アカウントのみ格納する。
厳密な意味で、3つのアカウントストレージとアクセスシステムがサポートされている。それらの
1つは旧式である(smbpasswd)。すべての簡単なシステムには tdbsam
方式
を使用することを推奨する。ldapsam
はもっと大規模か、複雑なネット
ワークで使用すること。
厳格かつ文字通りの意味で、passdbバックエンドはアカウント格納メカニズム(あるいは方法) のみである。技術の選択はミスリードの可能性があるが、言い回しの選択で困っている。 この章では、ユーザーと信頼アカウントにフォーカスをあてたアカウント格納システムの 本質について記述する。信頼アカウントは2つの形式があり、それはマシン信頼アカウント (コンピュータアカウント)とドメイン間信頼アカウントである。それらはユーザーのような エントリとして扱われる。
Samba-3 は Samba-2.2.x の以下の機能について完全な下位互換性を提供する:
これは全く持ってバックエンドではないが、単純化のためにここに表示する。
Sambaは伝統的なUNIX/Linuxの/etc/passwd
と
/etc/shadow
形式のサブシテムに平文認証要求を渡す
ように設定できる。Pluggable Authentication Modules (PAM) サポートが
あるシステム上では、 全てのPAMモジュールがサポートされる。動作は、
Samba-2.2.x の場合と全く同様で、Microsoft Windowsクライアントにより
課されるプロトコルの制約も同様に適用される。平文パスワードの使用に
関する制約に関する詳細情報は、
技術情報の項を参照のこと。
このオプションは、Microsoft Windows LanMan と NT の暗号化パスワード
及び一部のアカウント情報を格納するフィールドを含む平文ASCII(テキスト)
レイアウトを維持するsmbpasswd
ファイルの継続的
使用を可能にする。この種のパスワードバックエンドは、Microsoft
Windows NT4/200xサーバーと包括的な相互運用を行うために必要な拡張
コントロールを提供するための、Microsoft Windows NT/200x SAM
(Security Account Manager)情報を一切格納しない。
このバックエンドは、Samba のより古いバージョンとの下位互換性のために のみ使用するべきである。将来のリリースでは、切り捨てられていくかもしれない。
これは、Samba-2.2.x LDAP スキーマ拡張を使用する、既存のOpenLDAP バックエンドとの継続的運用を可能にするパスワードバックエンドの オプションである。このオプションはマイグレーションツールとして 提供されているが、この時点で強制的にマイグレーションする意味はない。 このツールは最終的には切り捨てられることになる。
Samba-3では多数の新しいパスワードバックエンド機能が導入された。
このバックエンドは、ローカルサーバーに、リッチなデータベースバックエンドを 提供する。このバックエンドは、複数のドメインコントローラー(つまり、PDC+ 一つ以上のBDCをインストールしている場合には適さない。
tdbsamパスワードバックエンドは古い smbpasswd情報のほかに、拡張された Microsoft Windows NT/200xのSAM情報をバイナリ形式のTDB(トリビアルデータベース) ファイルに格納する。拡張情報を含むことで、Samba-3が、Microsoft Windows NT4/200x ベースのシステムと同様のアカウントアクセス及びシステムアクセス制御を実現する ことを可能にする。
tdbsamを入れたのは、OpenLDAPを稼動する伴う 複雑性と、その間接費用を発生させずに、シンプルななサイト運用を 可能にしたいというユーザーからの要求にに直接応えるためである。これは、 ユーザー数250未満のサイトにのみ推奨する。これより大規模のサイト、 または実装では、OpenLDAP の使用またはActive Directoryへの統合を強く 推奨する。
これは、分散アカウントを導入している場合に、リッチなディレクトリバックエンド を提供する。
Samba-3ではLDAP用拡張の実装が新しくなり、これにより新しい形式のSambaスキーマを
持つOpenLDAPの設定を必要とする。新しい形式のスキーマファイルは、Samba
ディストリビューションの
examples/LDAP
のディレクトリにある。
新しいLDAPの実装は、Sambaの過去のバージョンで可能だったコントロール能力を 著しく向上するものである。このバージョンでは、“ユーザーごとの” プロファイル設定、ホームディレクトリ、アカウントアクセス制御、その他 多くの設定が可能になった。企業サイトでは、機能性と拡張性の向上要求に、 Sambaチームがしっかり耳を傾けたと いうことが理解できるはずである。
古いWindowsクライアントは、平文パスワードを送信する。Sambaはこれらの パスワードを暗号化し、UNIXユーザーデータベースに格納されているハッシュと 比較することにより、確認することができる。
より新しいWindowsクライアントは、平文パスワードのかわりに、暗号化された パスワード(Lanman及びNTハッシュと呼ばれるもの)を送信する。最新のクライアントは、 暗号化されたパスワードのみを送信し、クライアントのレジストリが改変されていない 限り、平文パスワードを送信することを拒否する。
Sambaはなぜ単純にUNIXパスワードデータベースを使うことが出来ないかという質問は 多くの人から聞く。Windowsは、パスワードに対してそれ固有の暗号化形式を要求する。 WindowsのパスワードはUNIX形式の暗号化パスワードに変換できない。そのため、標準 UNIXユーザーデータベースを使うことが出来ず、Lanman ハッシュとNTハッシュは別の所に 格納しなければならない。
パスワードの暗号化方式が異なるのみならず、WindowsはUNIXユーザーデータベースには
格納されないような各ユーザーに関する特定のデータを格納する。例えば、ユーザーが
ログインする可能性のあるワークステーション、ユーザーのプロファイルが格納されて
いる場所等々である。Sambaはpassdb backendを使用して
この情報を取り出し、格納する。 通常、使用できるバックエンドは、LDAP、tdbsum
および平文ファイルである。passdb backendのパラメーター
に関する詳細は、smb.conf
のマニュアルページを参照のこと。
SIDのUIDへの解決は、Samba の適正運用の根幹を成す。以下の両例で、winbinddが 稼動していないか、あるいは、接続できない状況のとき、ローカルのSID/UID解決 のみが可能である。SIDのUIDへの解決 およびUIDのSIDへの解決の図を参照のこと。
UNIXとSMBのパスワード暗号化のテクニックは、一見、類似しているように見える。しかし、 この類似性は、皮一枚だけの表面的なものである。。UNIXのスキームでは、通常 ログインの際に、 平文パスワードをネットワークを通して送信します。これは悪い方法である。SMBの暗号化 スキームは、ネットワークを通して平文パスワードを送信することは絶対にないが、ディスク上に 16バイトのハッシュ値を格納する。これも悪い方法である。なぜか。それは、16バイトのハッシュ 値は、“パスワードと同等”だからである。ユーザーのパスワードをハッシュ値から 導き出すことはできないが、クライアントに手を加えれば、サーバーにアクセスするために使える 可能性がある。これは、侵入者の側にかなりの技術的知識があることを前提としてるが、それでも 可能であることは確かである。従って、(smbpasswdファイル、 LDAP)いずれのパスワードデータ ベースバックエンドを使用していても、そこに格納されたデータが、全ユーザーの平文パスワードを 持っているかのように、慎重に取り扱わなければならない。これらのデータベースの内容は極秘とし、 ファイルは、適切に保護されていなければならない。
理想的には、ネットワーク上でもディスク上でも平文パスワードを持ったり送信したり しないようなパスワードのスキームが欲しいところである。残念ながら、Sambaは他の SMBシステム(Windows NT、Windows for Workgroups、Windows 9x/Me)との互換性を 確保しなければならないという要件のために、これは実現できない。
Windows NT 4.0 サービスパック 3は既定値で平文パスワードの送信を無効化している。 これにより、暗号化されたパスワードのサポートを使用するか、平文パスワードを再度 有効化するように Windows NT レジストリを編集するか、どちらかが必要となる。
Microsoft Windowsの下記のバージョンは、ドメイン環境にログオンする可能性があるにも かかわらず、完全なドメインセキュリティのプロトコルをサポートしていない:
MS DOS ネットワーククライアント3.0で基本的なネットワーク リダイレクタがインストールされているもの
Windows 95で、アップデートされたネットワークリダイレクタがインストールされているもの
Windows 98 [Second Edition]
Windows Me
下記のバージョンのMicrosoft Windowsは、ドメインセキュリティのプロトコルを完全にサポートしている。
Windows NT 3.5x.
Windows NT 4.0.
Windows 2000 Professional.
Windows 200x Server/Advanced Server.
Windows XP Professional.
Microsoft SMB/CIFS クライアントの現在のリリース版は全て、ここに説明するSMBの チャレンジ/ レスポンス認証の仕組みをサポートしている。平文認証を有効化しても、 クライアントが暗号化による認証に参加する能力を無効化するわけではない。そうではなく、 クライアントが平文でも暗号化でもどちらのパスワード認証方式にも対応できるようにする。
Microsoft Windowsのクライアントは、暗号化されたパスワードのみキャッシュする。 レジストリの変更により、平文パスワードが再度有効化されても、平文パスワードは キャッシュされない。このことは、ネットワーク接続が切れた場合、 キャッシュされた (即ち暗号化された)パスワードのみがリソースサーバーに送られて、自動再接続を実行する ために使用されるということを意味する。リソースサーバーが暗号化された パスワードを サポートしていない場合、自動再接続はできない。暗号化されたパスワードの使用を強く 推奨する。
Microsoft Windows NT4/200xがセキュリティ識別子(SID)を要求するのと同様に、 UNIX/Linuxの全ての操作は、ユーザー識別子(UID)を要求する。SambaはMicrosoft Windows のユーザーをUNIX/LinuxのUID にマッピングするために、二つの方法を提供する。
第一に、すべてのSamba SAM(セキュリティアカウントマネージャデータベース) アカウントが、そのアカウントとマッピングされるべきUNIX/Linux UID を必要とする。 アカウント情報データベースにユーザーが追加されるにつれ、SambaはSambaのホストOSに そのアカウントを追加するために、add user script インタフェースを呼ぶ。本質的には、ローカルSAMの中の全アカウントが、 ローカルユーザーアカウントを必要とする。
Windows SIDをUNIX UIDにマップする2番目の方法は、smb.conf
中の
idmap uidとidmap gidパラメーターを経由する
方法である。これらのパラメーターの情報についてはマニュアルページを参照のこと。リモート
(非メンバーのWindowsクライアントあるいは外部ドメイン)SAMサーバーからのユーザーマッピング
時にはこれらのパラメーターは不可欠である。
Samba-3は、分散ネットワーク環境中で、すべてのサーバー上で同一のUIDとGIDを使うことを
可能にする特別な機能を持っている。分散ネットワークとは、PDCが存在するもの、一つ以上の
BDCがあるもの、あるいは1つ以上のドメインメンバーサーバーがあるものである。なぜこれが
重要かというと、ファイルが1つ以上のプロトコル(たとえばNFS)で共有され、たとえば
rsync
のようなツールを使ってUNIX/Linuxシステム間で、ユーザーが
ファイルをコピーすることがあるからである。
idmap backend
と呼ばれるパラメーターを使って、
特別な機能を有効に出来る。このパラメーターの既定値は空の文字列である。
技術的に、LDAPベースのidmapバックエンドをUIDとGID向けに使うことは可能
であるが、SAMバックエンド用にLDAPの使用も行うネットワーク設定用にこれを
使う時にこれは最も意味を持つ。この設定については
LDAP idmap バックエンドを使う設定例
にある。
LDAPバックエンドに重要な仕事をさせたいネットワーク管理者は、遅かれ 早かれPADLソフトウェアによって優れた功績を知ることになろう。 PADL http://www.padl.comはとても興味深い一連の ツールをオープンソースで作成し、公開している。これらのツールは 以下を含む:
nss_ldap:AIX、Linux、Solarisやその他のOS向けの ネイティブなネームサービスサポートを提供するLDAPネームサービススイッチ (NSS)モジュール。このツールはUID/GIDの一元的な格納と検索に使う ことができる。
idmap_ad:PADL Web サイト からの、Microsoftサービスのための、UNIX RFC2307スキーマを サポートするIDMAPバックエンド。
現在の情報技術界で、多くの興奮と関心がLDAPディレクトリに向けられている。 LDAPアーキテクチャは高度に拡張性があるように設計された。また、広範囲な OSとプラットフォームを取り巻く、非常にたくさんのアプリケーションの潜在的 な領域をまたがって使うようにも設計されている。LDAP技術は会社全体のシングル サインオン(SSO)環境の基盤となる連携アイデンティティ管理(FIM)ソリューション の中心部をなしている(訳注:TivoliとかRSAでこのような製品がある様子)。
LDAPの実装は広範囲な種類のプラットフォームで構築されている。これは、 Microsoft Windows Active Directory(ADS)、NovellのeDirectoryやその他の もののの中心に位置する。LDAPによるディレクトリサービスの実装は、 新しい世代のアプリケーションと同様に古いものとも相互に関係し、 それらはすべて何らかの認証サービスに依存する。
UNIXのサービスは、ツールやユーティリティを介することによって、LDAPディレクトリ の情報を認証のために利用することが出来る。LDAPディレクトリ とミドルウェアのツールとユーティリティからなる統合環境により、すべての ユーザーが一元管理されたUNIXプラットフォームにアクセスすることが可能になる。 プラットフォームは、必要に応じて物理的に分散配置されてもよい。この機構の 恩恵を受けるアプリケーションとしては、UNIXログインシェル、メールとメッセージ システム、quota制御、印刷システム、DNSサーバー、DHCPサーバーやもちろんSambaも 含まれる。
多くのサイトが、Samba用に拡張性のあるpassdbバックエンドを提供するために、 まずはじめにLDAPをインストールする。その他はSamba SAMバックエンドのような 新しいユーザーのために存在するLDAPディレクトリに適合することが必要な場面に 直面する。Sambaに対する特別な必要性と魅力が何であっても、LDAPディレクトリ 構造とその実装のデザインに関する決定は、そのサイトの永続的な本質である。 これらは、長期にわたる情報システム管理コストに影響する広範囲な影響がある。
LDAPの展開を急いではならない。どのように、ディレクトリ情報ツリーが現在と 将来のサイトのニーズに影響するかのデザインを、それらが使える可能性と同じ ように理解する時間を取ること。SambaのSAM情報は、サイトからサイトに異なる DIT内に格納すべきであり、おのおのの実装において新しい経験が得られる。 最初の実装で目が覚め、2番目の実装では心配事が出来、三世代目でやっとうまく いくというのは、LDAPのベテランはよく理解していることである。
SambaはUNIX POSIX識別情報を、SambaとWindowsネットワーク環境に特有の 情報を格納する場所と同様に必要とする。取り扱われなければならない、 最もよく使われる情報はユーザーアカウント、グループアカウント、マシン 信頼アカウント、ドメイン間信頼アカウントとSamba内部で使う固有の中間 情報を含む。
この文書中の、展開ガイドラインは、他の本とインターネット上で公開されて いるHOWTO文書と同じように、出来上がっているディレクトリデザインと実装に 適合するわけではない。存在するDITは、共通のソース中で提案された単純な 情報レイアウトに適合することが出来ないかもしれない。更に追加すると、 Samba用に使われるLDAPディレクトリを提供するのに使われる共通スクリプトと ツールはあなたの要求に適合しないかもしれない。
これは一般的ではないが、存在するLDAP DITを持つサイトのために、サイト 固有のスクリプトとユーティリティ一式を作成する必要がある場合に、サイト 操作のスコープ内でSambaを供給することは可能である。DITを使ってユーザーと グループアカウントを配布する方法はこれをチャレンジングなことにさせる。 解決方法は、もちろん、価値があることであるが、それを行うための試行錯誤は チャレンジングである。サイトの要求を理解する時間を取り、急いで提供する ことは避けること。
上記から、サイトに適合しないスクリプトとツールをむやみやたらに使わないこと。 存在する基盤が、不適切なツールの不用意な使用によって被害を被らないことを 確実にするために、すべてのスクリプトを、それを実行する前に検査して検証すること。
SambaはLDAPに対するターンキーソリューションを提供しない。Sambaとの統合の 前に、LDAPのデザインと設定を行う事は最も良いことである。LDAPの実用的な 知識はSambaの統合を容易にし、LDAPの知識がない場合には、いらいらした経験 しか得られない。
コンピュータ(マシン)アカウントは、この章で説明されている、若干の制約を 受けるLDAPディレクトリサブジェクト中の好みの位置に配置できる。
コンピュータ(マシン)アカウントのPOSIXとsambaSamAccountコンポーネントは、 両者ともSambaによって使われる。そのため、マシンアカウントは、Windows NT/200xが扱うのと同じ方法で、Samba内部で扱われる。ユーザーアカウントと マシンアカウントは、マシンアカウントが$文字で終わることを除いてお互い を識別できず、信頼アカウントも同じである。
有効なUNIX uidに結びつくWindowsのユーザー、グループ、マシン、信頼およびその他の アカウントの必要性は、遙か昔前のSambaの開発時に決められた。この決定が覆されたり 変更することは、Samba-3.x系列の間にはありそうもない。
Windows SIDからのUID解決はSambaが動作しているホストOSを参照しなければならない メカニズムによって、Samba内で行われる。NSSは、それが動いているすべてのホスト OSについて全部を知る必要があるということから、(Sambaのような)アプリケーション を隠蔽する良いメカニズムである。
SambaはNSS制御(設定)ファイル中の“passwd”、“shadow” と“group”機能経由でホストOSが提供するUIDを問い合わせる。これを 達成するための最適なツールはUNIX管理者の決定にゆだねられている。それはSamba によっては強制されない。Sambaは1つの方法としてそのサポートライブラリとwinbindd を提供する。これをLDAP経由で行う事は可能で、すべてのアカウントエンティティが LDAPディレクトリ中にあることが可能なような適切なフックを提供する。
多くの人に対して、良い選択肢は、PADL nss_ldapライブラリを使うことである。 このユーティリティは、コンピュータアカウントがPOSIX/UNIXアカウントのUID に解決できるように設定されねばならない。これは基本的にLDAPのデザインの問題 である。Sambaメーリングリストとドキュメントで提供される情報は役に立つ例だけ を提供するようになっている。LDAPディレクトリのデザインは複雑な問題であり、 この文書の範囲外である。
Sambaはユーザーとマシンアカウントを管理するための2つのツールを提供する:
smbpasswd
とpdbedit
である。
pdbedit
はSambaユーザーアカウント情報に加えてアカウントポリシーを
管理するために使うことが出来る。ポリシー管理機能は、パスワードのエージングと
ログイン失敗の扱いの管理を行うドメインの既定値の設定を管理するために使われる。
何人かは、名前がSambaSAMAccount情報への格納メカニズムを参照しているために、
参照がsmbpasswd
担っていることに困惑することがある。
しかし、これはユーティリティツールの名前でもある。このツールは結局、
net
ツールセット(Netコマンドを参照)
という、新しく追加された新しい機能に取り替えられることになる。
smbpasswd
はpasswd
とyppasswd
プログラムに似たユーティリティである。これはpassdbバックエンド中の2つの32バイト
パスワードフィールドを管理する。このユーティリティは実際のアカウントと、(smb.conf
ファイル中の passdb backend
によって指定される)パスワード
格納方式とは独立して動作する。
smbpasswd
は、ユーザーのパスワードを変更する時に、ローカルのsmbd
に接続する時にクライアント-サーバーモードで動作する。これは非常なメリットがある。
smbpasswd
はWindows NT上のパスワードを変更する能力もある(これは
NTドメインのユーザーのパスワードを変更する時に、NT PDCにその要求を送る時にのみ動作
する)。
ユーザーまたはマシンアカウントの追加。
ユーザーまたはマシンアカウントの削除。
ユーザーまたはマシンアカウントの有効化。
ユーザーまたはマシンアカウントの無効化。
ユーザーパスワードの削除。
ドメイン間信頼アカウントの管理。
通常のユーザーでsmbpasswdを実行するには、以下のように入力する:
$
smbpasswd
Old SMB password:
secret
secret
には、古いパスワードを入力するか、もしも
古いパスワードがなければ単にリターンキーのみを入力する。
New SMB Password:
new secret
Repeat New SMB Password:
new secret
もしも古い値が、このユーザーに対して格納されている現在の値と異なる場合か、 2つの新しい値が一致しない場合、パスワードは変更されない。
普通のユーザーによって起動された場合、コマンドはそのユーザーのみのSMBパスワード のみ変更できる。
rootで実行される場合、smbpasswd
はSMBパスワードを変更
したいユーザー名をオプションの引数として指定できる。rootで実行される場合、
smbpasswd
は古いパスワードの値をチェックするための
プロンプトを出さないので、パスワードを忘れたユーザーのパスワードを設定できる。
smbpasswd
は、passwd
やyppasswd
コマンドを使っているUNIXユーザーに親しみやすい方法で動作するように設計されて
いる。管理用として設計されているが、このツールは基本的なユーザーレベルの
パスワード変更機能を提供する。
pdbedit
はrootでのみ使えるツールである。これは、
ドメイン全体でのアカウントポリシーの設定のようにpassdbバックエンド
を管理するのに使われる。pdbedit
は以下のように使える:
ユーザーアカウントの追加、削除および変更。
ユーザーアカウントの表示。
ユーザーアカウントの移行(migrate)。
グループアカウントの移行。
アカウントポリシーの管理。
ドメインアクセスポリー設定の管理。
上場企業会計改革および投資家保護法(いわゆる米国SOX法)下で、アメリカの企業と
組織は一連の内部統制
と伝達手段、記録、会計データの
保護を実施することが必要となった。米国SOX法はさらに以下の点についても影響
する:
財務データを格納する情報システムにだれがアクセスするかということ。
どのように個人情報と会計情報が、従業員とビジネスパートナーとの間で扱われるかと言うこと。
どのようにセキュリティの欠陥を管理するかと言うこと。
すべての情報システムへのセキュリティとパッチレベル管理。
どのように情報システムの変更が文書化され、追跡できるようになるかと言うこと。
どのように情報アクセス制御が実装されて管理されているかと言うこと。
変更点とセキュリティに関するすべての情報システムの監査機能。
プライバシーを確実にするための規律手順と制御。
手短に言うと、米国SOX法は、ビジネス関連の情報システムに関して責任を 強める道具である。特に会計データ処理と個人情報の記録に使われるすべての 情報システムのコンプライアンスを強化する。同様な責任は世界中で要求され ている。
政府の法律に従って情報システム操作を許可するSambaのツールと機能に
精通している必要性は明らかである。pdbedit
は
アカウントとシステムアクセス制御とポリシーを管理する能力を提供する
唯一のSambaツールである。Samba-3シリーズの残存ライフサイクル中、
この重要な領域で新しいツールが実装されることはあり得る。
Sambaと比較した場合のWindows NT4で有効なドメイングローバルポリシー 制御はNT4 ドメイン対 Sambaポリシー制御 中にある。
Table 11.1. NT4ドメイン対Sambaポリシー制御
NT4ポリシー名 | Sambaポリシー名 | NT4 レンジ | Samba レンジ | Samba 既定値 |
---|---|---|---|---|
Maximum Password Age(パスワード有効期間) | maximum password age | 0 - 999 (日) | 0 - 4294967295 (秒) | 4294967295 |
Minimum Password Age(パスワード変更禁止期間) | minimum password age | 0 - 999 (日) | 0 - 4294967295 (秒) | 0 |
Mimimum Password Length(最小パスワード長) | min password length | 1 - 14 (文字) | 0 - 4294967295 (文字) | 5 |
Password Uniqueness(パスワード履歴) | password history | 0 - 23 (#) | 0 - 4294967295 (#) | 0 |
Account Lockout - Reset count after(アカウントロックアウト期間) | reset count minutes | 1 - 99998 (分) | 0 - 4294967295 (分) | 30 |
Lockout after bad logon attempts(ロックアウトの閾値) | bad lockout attempt | 0 - 998 (#) | 0 - 4294967295 (#) | 0 |
*** Not Known *** | disconnect time | TBA | 0 - 4294967295 | 0 |
Lockout Duration(ロックアウト閾値のリセット) | lockout duration | 1 - 99998 (min) | 0 - 4294967295 (min) | 30 |
Users must log on in order to change password | user must logon to change password | 0/1 | 0 - 4294967295 | 0 |
*** Registry Setting *** | refuse machine password change(マシンパスワード変更の禁止) | 0/1 | 0 - 4294967295 | 0 |
pdbedit
ツールはアカウントセキュリティとポリシー
設定を管理できる唯一のツールである。これは、smbpasswdが出来ること
と同様のことを含むスーパーセットである。
pdbedit
の用途の中で特に重要なものの一つとして、
passdbバックエンドから他へのアカウント情報のインポート/エクスポート
機能がある。
pdbedit
ツールはsmbpasswd
ツールと
同様、UNIX/Linuxシステムアカウントデータベース(バックエンド)中にすでに
存在するPOSIXユーザーアカウントを必要とする。システム管理者の責任と
考えられるので、ユーザーアカウントを作成するためにOSを呼び出すことは
どちらのツールも行わない。NT4のドメインユーザーマネージャがアカウント
を追加するために使われた時、Sambaは、ユーザー、グループ、マシンアカウント
が正しく作成され、変更されることを行うために、(他のインタフェース
スクリプトと同様)add user script
を使う。
pdbedit
ツールを使用しても、それらのインタフェース
スクリプトは使わない。
pdbedit
を、ユーザーとマシンアカウントを管理
するために使うことを試みる前に、システム(POSIX)アカウントが
すでに作成されているかを確かめておくこと。
以下は、tdbsamパスワードバックエンド中に格納されているユーザーアカウント 情報の例である。表示は以下のコマンドを実行することで行える:
$
pdbedit -Lv met
UNIX username: met NT username: met Account Flags: [U ] User SID: S-1-5-21-1449123459-1407424037-3116680435-2004 Primary Group SID: S-1-5-21-1449123459-1407424037-3116680435-1201 Full Name: Melissa E Terpstra Home Directory: \\frodo\met\Win9Profile HomeDir Drive: H: Logon Script: scripts\logon.bat Profile Path: \\frodo\Profiles\met Domain: MIDEARTH Account desc: Workstations: melbelle Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 20:14:07 GMT Kickoff time: Mon, 18 Jan 2038 20:14:07 GMT Password last set: Sat, 14 Dec 2002 14:37:03 GMT Password can change: Sat, 14 Dec 2002 14:37:03 GMT Password must change: Mon, 18 Jan 2038 20:14:07 GMT
root#
pdbedit -Lw
root:0:84B0D8E14D158FF8417EAF50CFAC29C3: AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U ]:LCT-42681AB8: jht:1000:6BBC4159020A52741486235A2333E4D2: CC099521AD554A3C3CF2556274DBCFBC:[U ]:LCT-40D75B5B: rcg:1002:E95D4331A6F23AF8AAD3B435B51404EE: BB0F2C39B04CA6100F0E535DF8314B43:[U ]:LCT-40D7C5A3: afw:1003:1AAFA7F9F6DC1DEAAAD3B435B51404EE: CE92C2F9471594CDC4E7860CA6BC62DB:[T ]:LCT-40DA501F: met:1004:A2848CB7E076B435AAD3B435B51404EE: F25F5D3405085C555236B80B7B22C0D2:[U ]:LCT-4244FAB8: aurora$:1005:060DE593EA638B8ACC4A19F14D2FF2BB: 060DE593EA638B8ACC4A19F14D2FF2BB:[W ]:LCT-4173E5CC: temptation$:1006:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: A96703C014E404E33D4049F706C45EE9:[W ]:LCT-42BF0C57: vaioboss$:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 88A30A095160072784C88F811E89F98A:[W ]:LCT-41C3878D: frodo$:1008:15891DC6B843ECA41249940C814E316B: B68EADCCD18E17503D3DAD3E6B0B9A75:[W ]:LCT-42B7979F: marvel$:1011:BF709959C3C94E0B3958B7B84A3BB6F3: C610EFE9A385A3E8AA46ADFD576E6881:[W ]:LCT-40F07A4
このコマンドが返すアカウント情報は、左から右に、以下の、コロンで 分離されたデータを含む:
ログインID。
UNIX UID。
Microsoft LanManagerパスワードハッシュ(パスワードは大文字に変換された後ハッシュされる)。
Microsoft NTパスワードハッシュ(大文字小文字の状態を保持したパスワードのハッシュ)。
Samba SAM アカウントフラグ。
LCTデータ(パスワード最終変更時刻)。
アカウントフラグパラメーターはpdbedit
マニュアルページに
説明があり、
アカウントフラグ管理の節
で簡単に説明されている。
pdbedit
は、スタンドアロンサーバーまたはドメインに
ユーザーアカウントを追加する時に使える。ここで紹介する例では、
vlaan
というユーザーのアカウントが、SambaSAMAccount
を追加する前に作成されている。
root#
pdbedit -a vlaan
new password: secretpw
retype new password: secretpw
Unix username: vlaan
NT username: vlaan
Account Flags: [U ]
User SID: S-1-5-21-726309263-4128913605-1168186429-3014
Primary Group SID: S-1-5-21-726309263-4128913605-1168186429-513
Full Name: Victor Laan
Home Directory: \\frodo\vlaan
HomeDir Drive: H:
Logon Script: scripts\logon.bat
Profile Path: \\frodo\profiles\vlaan
Domain: MIDEARTH
Account desc: Guest User
Workstations:
Munged dial:
Logon time: 0
Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time: Mon, 18 Jan 2038 20:14:07 GMT
Password last set: Wed, 29 Jun 2005 19:35:12 GMT
Password can change: Wed, 29 Jun 2005 19:35:12 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
以下のコマンドを実行することで、SambaSAMAccountデータベースから アカウントを削除できる。
root#
pdbedit -x vlaan
アカウントは出力結果なしで削除される。アカウントはSambaSAMAccount (passdb バックエンド)データベースからのみ削除され、UNIXアカウント バックエンドからは削除されない。
アカウントを削除するためにNT4ドメインユーザーマネージャを使うと、
delete user script
を起動するが、それは
pdbedit
ツールではない。
pdbedit
マニュアルページにこのツールで有効な
すべての操作の完全な詳細が記述されている。
下記は、ユーザーアカウント情報の、フルネーム情報を変更する例である:
root#
pdbedit -r --fullname="Victor Aluicious Laan" vlaan
...
Primary Group SID: S-1-5-21-726309263-4128913605-1168186429-513
Full Name: Victor Aluicious Laan
Home Directory: \\frodo\vlaan
...
ユーザーのパスワードが満了して、ユーザーがパスワードを変更できなくなった を仮定してみよう。そのアカウントと本来のパスワードで作業が出来るように するには、ユーザーに追加の猶予時間が必要かもしれない。これは、どのように パスワード満了の設定を更新できるかの例を示している。
root#
pdbedit -Lv vlaan
...
Password last set: Sun, 09 Sep 2001 22:21:40 GMT
Password can change: Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password : Thu, 03 Jan 2002 15:08:35 GMT
Bad password count : 2
...
ユーザーは2回ログオンに失敗し、次でアカウントがロックされるが、 パスワードはすでに満了している。以下で、どのようにこのアカウントを リセットするかを示す。
root#
pdbedit -z vlaan
...
Password last set: Sun, 09 Sep 2001 22:21:40 GMT
Password can change: Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 03 Jan 2002 15:08:35 GMT
Last bad password : 0
Bad password count : 0
...
Password must change:
パラメーターは以下のようにして
リセットする:
root#
pdbedit --pwd-must-change-time=1200000000 vlaan
...
Password last set: Sun, 09 Sep 2001 22:21:40 GMT
Password can change: Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Thu, 10 Jan 2008 14:20:00 GMT
...
別の方法として、このツールで日付を設定する方法もある:
root#
pdbedit --pwd-must-change-time="2010-01-01" \
--time-format="%Y-%m-%d" vlaan
...
Password last set: Sun, 09 Sep 2001 22:21:40 GMT
Password can change: Thu, 03 Jan 2002 15:08:35 GMT
Password must change: Fri, 01 Jan 2010 00:00:00 GMT
...
時刻の形式についての情報は、strptimeマニュアルページを参照のこと。
SambaSAMAccountの操作に関するさらなる情報はpdbeditのマニュアルページ を参照のこと。
Samba SAMアカウントフラグはSambaソースコード中で、ACB (account control block)と呼ばれている。Sambaソースコードの一部では、 これらはaccount encode_bitsやaccount control flagsとしても参照される。
手動での、ユーザー、マシン(ワークステーションまたはサーバー)、あるいは
ドメイン間信頼アカウントのアカウントフラグの調整は、通常Sambaを
使用している場合には必要ない。別の観点からすると、何らかの理由で
この情報が壊れた場合、壊れたデータの修正ができる可能性があると便利で
ある。そのような修正のためのツールの選択枝はpdbedit
ユーティリティである。
固有のSamba管理ツールを作成する開発者からアカウントフラグの情報に関する いくつかの要求があった。アカウントフラグの適切な管理に関する必要な情報 例は、LDAPディレクトリを管理するためのスクリプトの開発時に明白である。
アカウントフラグフィールドは最大16文字である。現在11個が使われている。
Samba SAM Accountコントロールブロックフラグ
に一覧がある。pdbedit
コマンドによって指定されたフラグの
順番に意味はない。実際、LDAPディレクトリ中のSambaAcctFlagsレコード中を
どのような順番にしても問題はない。
Table 11.2. Samba SAM Accountコントロールブロックフラグ
フラグ | 説明 |
---|---|
D | アカウントが無効。 |
H | ホームディレクトリが必要。 |
I | ドメイン間信頼アカウント。 |
L | アカウントが自動ロックされている。 |
M | MNS (Microsoft network service)ログオンアカウント。 |
N | パスワードが不要。 |
S | サーバー信頼アカウント。 |
T | 一時的な重複アカウントエントリ。 |
U | 通常のユーザーアカウント。 |
W | ワークステーション信頼アカウント。 |
X | パスワードは満了していない。 |
アカウントコントロールフラグを設定するためのpdbedit
使用例は以下の通り:
root#
pdbedit -r -c "[DLX]" jht
Unix username: jht
NT username: jht
Account Flags: [DHULX ]
User SID: S-1-5-21-729263-4123605-1186429-3000
Primary Group SID: S-1-5-21-729263-4123605-1186429-513
Full Name: John H Terpstra,Utah Office
Home Directory: \\aurora\jht
HomeDir Drive: H:
Logon Script: scripts\logon.bat
Profile Path: \\aurora\profiles\jht
Domain: MIDEARTH
Account desc: BluntObject
Workstations:
Logon time: 0
Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time: 0
Password last set: Sun, 03 Jul 2005 23:19:18 GMT
Password can change: Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
root#
pdbedit -r -c "[]" jht
Unix username: jht
NT username: jht
Account Flags: [U ]
User SID: S-1-5-21-729263-4123605-1186429-3000
Primary Group SID: S-1-5-21-729263-4123605-1186429-513
Full Name: John H Terpstra,Utah Office
Home Directory: \\aurora\jht
HomeDir Drive: H:
Logon Script: scripts\logon.bat
Profile Path: \\aurora\profiles\jht
Domain: MIDEARTH
Account desc: BluntObject
Workstations:
Logon time: 0
Logoff time: Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time: 0
Password last set: Sun, 03 Jul 2005 23:19:18 GMT
Password can change: Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
設定されているドメインアカウントアクセスポリシーを見るためには以下を実行する:
root#
pdbedit -P ?
No account policy by that name
Account policy names are :
min password length
password history
user must logon to change password
maximum password age
minimum password age
lockout duration
reset count minutes
bad lockout attempt
disconnect time
refuse machine password change
ドメインに対する以下の制御を確立するとする:
min password length = 8 characters.
password history = last 4 passwords.
maximum password age = 90 days.
minimum password age = 7 days.
bad lockout attempt = 8 bad logon attempts.
lockout duration = forever, account must be manually reenabled.
以下のコマンドでこれらの設定を実行する:
root#
pdbedit -P "min password length" -C 8 account policy value for min password length was 5 account policy value for min password length is now 8root#
pdbedit -P "password history" -C 4 account policy value for password history was 0 account policy value for password history is now 4root#
pdbedit -P "maximum password age" -C 7776000 account policy value for maximum password age was 4294967295 account policy value for maximum password age is now 7776000root#
pdbedit -P "minimum password age" -C 7 account policy value for minimum password age was 0 account policy value for minimum password age is now 7root#
pdbedit -P "bad lockout attempt" -C 8 account policy value for bad lockout attempt was 0 account policy value for bad lockout attempt is now 8root#
pdbedit -P "lockout duration" -C -1 account policy value for lockout duration was 30 account policy value for lockout duration is now 4294967295
最大(無限)なロックアウト時間を設定するためには値として-1を使用する。
アカウントポリシーはおのおののPDCとBDC上で個別にに設定する必要がある。この時点 (Samba 3.0.11からSamba3.0.14a)で、アカウントポリシーは自動的に複製されない。 これはSamba3.0.20がリリースされるか、それより少し後に修正される予定である。 Samba-3リリースファイル中の、この機能に関する特定の更新情報がある WHATSNEW.txt ファイルをチェックしてみること。
Sambaはバックエンドアカウントデータベースのデザインに柔軟性を提供する。この柔軟性 は探せばすぐに見つかる。Sambaにおける最近の変更(Samba 3.0.23以降)はいくつかのインストール時 にうまくいかなくなる問題を単純化するために複数バックエンド機能が削除された。この 削除によりSamba-3の内部動作はより首尾一貫し安定した。
Samba 3.0.23から、もはや複数のpassdbバックエンドを指定して使うことは出来なくなった。 それ以前のSamba-3では、同じタイプのバックエンドを含む複数のpassdbバックエンドが指定できた。 複数のpassdbバックエンド機能は名前->SID変換とSID->名前解決で多くの問題を引き起こした。 Sambaチームはいろいろと検討した結果この機能を取り除く必要があると決定した。
古いバージョンのSambaではUNIXユーザーデータベースからユーザー情報を検索し、
結局いくつかの他のフィールドは/etc/samba/smbpasswd
か/etc/smbpasswd
ファイルから得ていた。パスワードの
暗号化が無効になっている時、SMB固有のデータは全く格納されない。その代わり、
すべての操作はSambaホストOSがその/etc/passwd
データベースによってアクセスする方法経由で制御される。ほとんどのLinux
システムでは、たとえば、すべてのユーザーとグループの解決はPAM経由で行われる。
伝統的にencrypt passwords = yes
とSambaのsmb.conf
ファイル中で設定した時、ユーザー名、LM/NTパスワード
ハッシュ、パスワード変更時間とアカウントフラグのようなユーザーアカウント
情報はsmbpasswd(5)
ファイルに格納される。これは、
たくさんのユーザー(数千くらい)を抱えるサイトに対するアプローチとしては
不利である。
最初の問題は、すべての検索をシーケンシャルに行わなければならないという ことである。ドメインログオン時におおよそ二つの検索(1つは最初のログオン 検証で、もう1つはセッション接続セットアップで、それはネットワーク ドライブやプリンターのマッピング)が行われ、これは、大きなサイトでは、 性能のボトルネックになる。この場合必要なことは、データベースを使う ような、インデックスを使うアプローチである。
二番目の問題は、一つ以上のSambaサーバーにsmbpasswdファイルを複製しよう
とする管理者は、たとえば、rsync(1)
と
ssh(1)
と、内製したカスタムスクリプトのような
外部ツールを使う必要があるということである。
最後に、smbpasswdエントリ中に格納されている情報の量には、たとえば ホームディレクトリ、パスワード満了時刻や相対識別子(RID)のような 追加の属性を入れる領域がない。
上記のような機能不足の点から、ユーザー属性を格納するより堅牢な手段を smbdによって使うことが開発されてきた。ユーザーアカウントにアクセス することを定義するAPIは、共通的にsamdbインタフェースとして参照される (以前には、これはpassdb APIとして呼ばれていて、現在もSambaソース コード中ではそのように名前が付けられている)。
Sambaは、Samba平文データベースの機能不足点を克服する一連の拡張された passdbバックエンドを提供している。これらはtdbsamとldapsamである。 もちろん、ldapsamは、大きな会社や巨大サイトが興味を持つものである。
Sambaは“TDB”(trivial database)中にユーザーとマシンアカウント を格納できる。このバックエンドを使う時には追加の設定は不要である。 このバックエンドはLDAPを必要としない、新しくインストールする場合に 推奨される。
一般的なガイドとして、Sambaチームは250人あるいはそれ以上のユーザーが いるサイトに、tdbsamバックエンドを使うことを推奨していない。さらに 追加で、tdbsamは、アカウントデータベースを複製することが要求される PDC/BDC実装を要求するサイト中で使うための拡張性の能力はない。 明確にいうと、拡張性という理由で、ldapsamを使用すべきである。
250ユーザー制限は、純粋に、一般的に、おそらく一つ以上の物理配置 にまたがってばらけている、ルーティングネットワークを持つサイトを必要 とするという概念に基づく目安でしかない。Sambaチームは現時点で、tdbsam アーキテクチャのパフォーマンスベースの拡張性制限を把握していない。
数千のユーザーを抱えているが、1台のサーバーだけを必要とするサイトがある。
1つのサイトは最近UNIXシステム上で4500ユーザーを保持していることを報告し、
tdbsam
passdbバックエンドでよい性能が出たことを
報告した。tdbsam
passdbバックエンドを使う場合の制限は、
TDB格納場所の制限に関連し、それはSambaSAMAccountバックエンドのための
分散メカニズムの必要性にのみ基づく。
ldapsamが提供しないいくつかの弱点がある。この文書で参照されるLDAP サポートは以下を含まない:
Windows 200x Active Directoryサーバーからの ユーザーアカウント情報を検索する手段。
/etc/passwdを置き換える手段。
2番目の項目はLDAP NSSとPAMモジュールを使うことにより達成できる。LGPL バージョンのそれらのライブラリは PADL Softwareで作成されて いる。これらのパッケージに着いてのより詳細な情報は、 Gerald CarterによるLDAP, System Administration の第6章、NISを置き換えるを参照のこと。
このドキュメントでは、伝統的にsmbpasswd(5)ファイルに格納されている Sambaユーザーアカウント情報をLDAPディレクトリに格納するための使い方に ついて説明している。読者はすでに基本的なLDAPの概念とすでにインストール している動作中のディレクトリサーバーを持っていることを仮定している。 LDAPのアーキテクチャとディレクトリについてのより詳細な情報は、以下の サイトを参照してほしい:
有効に使える2つのSambaリソースは以下の通り:
The Samba-PDC-LDAP-HOWTO Ignacio Coupeauによって管理されている。
IDEALXからのNTマイグレーション スクリプトは、Samba-LDAPドメインコントローラー構成でユーザーとグループの 管理に関連づけるものである。Idealxはsmbldap-toolsと対話的な コンソール管理ツールも作成している。
LDAPのldapsamコードはOpenLDAP 2.xサーバーとクライアントライブラリを 使って開発とテストが行われている。同じコードはNetscape's Directory Server とクライアントSDKでも動作する。しかし、それらはコンパイルエラーとバグが 必ず生じる。それらを直すのはとても難しい。 バグ報告中で概要が説明されている手順 経由で修正を投稿してほしい。
Sambaは任意の標準準拠のLDAPサーバーとともに動作できる。
Samba-3.0はソースコードディストリビューション中の
examples/LDAP/samba.schema
中にある
OpenLDAP 2.x用に必要なスキーマファイルを用意している。
sambaSamAccountオブジェクトクラスのスキーマエントリは以下の通り:
ObjectClass (1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY DESC 'Samba-3.0 Auxiliary SAM Account' MUST ( uid $ sambaSID ) MAY ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $ sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $ sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $ displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $ sambaProfilePath $ description $ sambaUserWorkstations $ sambaPrimaryGroupSID $ sambaDomainName ))
samba.schema
ファイルはOpenLDAP 2.0/2.1
用の形式である。Sambaチームは上記のスキーマが使うOID空間を
所有し、この利用を推奨している。もしもNetscape DSが使うように
スキーマを変換したならば、
jerry@samba.org
にパッチとしてスキーマファイルを送ってほしい。
smbpasswdファイルが、ユーザーの/etc/passwd
エントリ
に追加の情報を提供する情報を格納するように、sambaSamAccountアカウント
オブジェクトはUNIXユーザーアカウント情報を補う。sambaSamAccountは
補助型
オブジェクトクラスであるので、LDAP
ディレクトリ中の存在するユーザーアカウント情報に付随するものとして
使うことが出来、Sambaアカウントの操作のために必要な情報を提供する。
しかし、RFC2307で定義されているposixAccountオブジェクトクラスと
重複するいくつかのフィールド(たとえばuid)がある。これは意図的なものである。
すべてのユーザーアカウント情報(UNIXとSamba)をディレクトリ中に格納する
ために、sambaSamAccountとposixAccountオブジェクトクラスを組み合わせて
使う必要がある。しかし、smbd
はそれでもgetpwnam()
のような標準Cライブラリコール経由でユーザーのUNIXアカウント情報を、
得ることがある。これは、SambaサーバーはLDAP NSSライブラリのインストールと
正しく動くための設定も必要とすることを意味する。このように情報を区分することで、
すべてのSambaアカウント情報をLDAP中に格納することが出来るようにするが、
ネットワークが完全なLDAP基盤に移行しながら、UNIX のアカウント情報は
NISで管理することができる。
OpenLDAPディレクトリサーバー中でsambaSamAccountのサポートを行うためには、
最初にsamba.schemaファイルをslapdの設定ディレクトリにコピーする。
samba.schemaファイルはSambaソースディストリビューション中の
examples/LDAP
ディレクトリ中にある。
root#
cp samba.schema /etc/openldap/schema/
次に、slapd.conf
中にsamba.schema
ファイルを含める。sambaSamAccountオブジェクトは他のスキーマファイルに
依存する2つの属性を含んでいる。uid
属性は
cosine.schema
中で定義され、
displayName
属性は
inetorgperson.schema
中で定義されている。両方は
samba.schema
ファイルの前で定義しておかなければならない。
## /etc/openldap/slapd.conf ## スキーマファイル(core.schemaは既定値で必要とされる) include /etc/openldap/schema/core.schema ## sambaSamAccountに必要なもの include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema ....
以下の例のように、sambaSamAccountオブジェクトクラス上での検索のスピード を上げるため、最もよく使う属性のいくつかにインデックスを付加することは 推奨される(そして、可能ならばそれはposixAccountとposixGroupも)。
# インデックスの管理 ## OpenLDAPで要求されるもの index objectclass eq index cn pres,sub,eq index sn pres,sub,eq ## pdb_getsampwnamをサポートするのに必要なもの index uid pres,sub,eq ## pdb_getsambapwrid()をサポートするのに必要なもの index displayName pres,sub,eq ## uncomment these if you are storing posixAccount and ## posixGroup entries in the directory as well ##index uidNumber eq ##index gidNumber eq ##index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub
以下を実行し新しいインデックスを作成する:
root#
./sbin/slapindex -f slapd.conf
上記の変更後、slapdを再起動するのを忘れないこと:
root#
/etc/init.d/slapd restart
LDAPデータベースにアカウントが追加できる前に、格納するためのアカウント コンテナを作成する必要がある。以下のLDIFファイルは必要に応じて変更 する必要がある(DNSエントリなど):
# Organization for Samba Base dn: dc=quenya,dc=org objectclass: dcObject objectclass: organization dc: quenya o: Quenya Org Network description: The Samba-3 Network LDAP Example # Organizational Role for Directory Management dn: cn=Manager,dc=quenya,dc=org objectclass: organizationalRole cn: Manager description: Directory Manager # Setting up container for Users OU dn: ou=People,dc=quenya,dc=org objectclass: top objectclass: organizationalUnit ou: People # Setting up admin handle for People OU dn: cn=admin,ou=People,dc=quenya,dc=org cn: admin objectclass: top objectclass: organizationalRole objectclass: simpleSecurityObject userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz # Setting up container for groups dn: ou=Groups,dc=quenya,dc=org objectclass: top objectclass: organizationalUnit ou: Groups # Setting up admin handle for Groups OU dn: cn=admin,ou=Groups,dc=quenya,dc=org cn: admin objectclass: top objectclass: organizationalRole objectclass: simpleSecurityObject userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz # Setting up container for computers dn: ou=Computers,dc=quenya,dc=org objectclass: top objectclass: organizationalUnit ou: Computers # Setting up admin handle for Computers OU dn: cn=admin,ou=Computers,dc=quenya,dc=org cn: admin objectclass: top objectclass: organizationalRole objectclass: simpleSecurityObject userPassword: {SSHA}c3ZM9tBaBo9autm1dL3waDS21+JSfQVz
上記で示されているuserPasswordはslappasswd
を使って
生成する必要がある。
以下のコマンドでLDAPデータベース中にLDIFの内容をロードする。
$
slapadd -v -l initldap.dif
adminパスワードと同様に、アクセス制御リストを十分に使ってLDAPサーバーの 安全性を確保することを忘れないこと。
以下のsmb.conf
中のパラメーターは、SambaがLDAPサポートを出来るように
構築された場合にのみ有効である。Sambaは、LDAPライブラリを見つけると、
自動的にLDAPをサポートするように構築する。LDAPをサポートしているか
否かを調べる最も良い方法は以下の通り:
root#
smbd -b | grep LDAP
HAVE_LDAP_H
HAVE_LDAP
HAVE_LDAP_DOMAIN2HOSTLIST
HAVE_LDAP_INIT
HAVE_LDAP_INITIALIZE
HAVE_LDAP_SET_REBIND_PROC
HAVE_LIBLDAP
LDAP_SET_REBIND_PROC_ARGS
もしも使用したsmbd
コマンドがHAVE_LDAP_H
を出力しない場合、なぜLDAPヘッダーとライブラリがコンパイル中に見つから
なかったかということを調べる必要がある。
LDAP関連のsmb.confオプションは以下の通り:
passdb backend = ldapsam:url |
これらはsmb.conf
マニュアルページに説明があり、ここでは繰り返さない。
しかし、LDAPディレクトリを使うための例は
LDAP使用の設定例にある。
Example 11.2. LDAP使用の設定例
ユーザーアカウントはsambaSamAccountオブジェクトクラスを通じて管理 されるため、使っている管理ツールをsambaSamAccount属性を扱えるよう に修正する必要がある。
マシンアカウントはsambaSamAccountオブジェクトクラスを使って管理
されるため、ユーザーアカウントと同じように扱われる。しかし、これらの
アカウントをLDAP名前空間の異なったツリーに格納することはそれも
可能である。グループを格納するために、
“ou=Groups,dc=quenya,dc=org”を使うべきであり、
ユーザーのために“ou=People,dc=quenya,dc=org”を
使うべきである。NSSとPAMの設定をそれに合わせて設定すること
(通常は、/etc/openldap/sldap.conf
設定
ファイル中で設定する)。
Samba-3では、グループ管理システムはPOSIXグループをベースにして
いる。これは、SambaはposixGroupオブジェクトクラスを使うという
ことを意味する。今の所、NT風のグループシステム管理はない(
グローバルとローカルグループという)。Samba-3は
Domain Groups
のみを認識し、Microsoft
Windows 2000と Active Directoryとは異なり、Samba-3はネスト
されたグループをサポートしない。
ディレクトリ中のsambaSAMAccountエントリについてのセキュリティに関する 議論の際に覚えておかなければならない2つの重要な観点がある。
これらのパスワードハッシュは平文と同等であり、オリジナルの平文 文字列を得ないでもユーザーを詐称するために使える。LM/NTハッシュ についてのより詳細な情報は、この章の アカウント情報データベース を参照のこと。
最初のセキュリティ問題に対応するため、ldap ssl
smb.conf
パラメーターは、ディレクトリサーバーに接続する際に、
既定値のポート636
を使う暗号化セッション
(ldap ssl = on)を既定値で
要求する。OpenLDAPサーバーを使う場合、LDAPSを指定する場所で、
StartTLS LDAP拡張操作を使うことが可能である。この場合、安全な
通信プロトコルを使うことを強く推奨する(そのため、
ldap ssl = offを設定しては
ならない)。
LDAPSプロトコルはLDAPv3 StartTLS拡張オプションが優先されるので、非推奨 であることに注意。しかし、OpenLDAPライブラリは引き続きクライ アントとサーバー間の古い安全な通信方法をサポートする。
次の安全対策は、管理者以外がディレクトリからパスワードハッシュを
得ることを防ぐことである。これはslapd.conf
中に以下のACLを設定することで行える:
## "ldap admin dn" アクセスは許可するがそれ以外は拒否 access to attrs=SambaLMPassword,SambaNTPassword by dn="cn=Samba Admin,ou=People,dc=quenya,dc=org" write by * none
sambaSamAccountオブジェクトクラスは以下の表にあるような属性の集合である: Part AとPart B。
Table 11.3. Attributes in the sambaSamAccountのオブジェクトクラス(LDAP), Part A
sambaLMPassword | 16進文字列表現で格納されているLanManパスワードの16バイトハッシュ値。 |
sambaNTPassword | 16進文字列表現で格納されているNTパスワードの16バイトハッシュ値。 |
sambaPwdLastSet | sambaLMPassword とsambaNTPassword が
最後に設定された時刻の、1970年からの経過秒数(整数値)。 |
sambaAcctFlags | 大カッコ[]で囲まれた11文字の文字列で、U(ユーザー)、W(ワークステーション)、 X(パスワード満了なし)、I(ドメイン信頼アカウント)、H(ホームディレクトリが必要)、 S(サーバー信頼アカウント)とD(無効)のようなアカウントフラグが格納。 |
sambaLogonTime | 未使用(整数値)。 |
sambaLogoffTime | 未使用(整数値)。 |
sambaKickoffTime | ユーザーがロックされてログインできなくなる時刻(UNIX時刻形式)を指定。 もしも属性が省略された場合、アカウントは決して満了しない。この 属性をshadowAccountオブジェクトクラスのshadowExpire属性と一緒に 使うことで正確な日時で完全にアカウントを満了できる。 |
sambaPwdCanChange | ユーザーにパスワード変更が許可されている時刻(UNIX時刻形式)。 もしもこの属性が設定されていない場合、ユーザーは任意の時刻に パスワードを変更できる。 |
sambaPwdMustChange | パスワードを強制的に変更しなければならない時刻(UNIX時刻形式)。 もしもこの値が0ならば、ユーザーは最初のログイン時にパスワードを変更 しなければならない。この属性が設定されていない場合、パスワードは 決して満了しない。 |
sambaHomeDrive | sambaHomePathによって指定されるUNCパスにマップされるドライブ 名を指定。ドライブ名はXがマップするドライブ名である、 “X:”という形式で指定する必要がある。 smb.conf(5)マニュアルページ中の“logon drive” パラメーターにある詳細を参照のこと。 |
sambaLogonScript | sambaLogonScriptプロパティは、.CMD, .EXE, や .BATファイルの
ようなユーザーのログオンスクリプトのパスを指定する。文字列は空
でもよい。パスはnetlogon共有からの相対パスである。詳細な情報は、
smb.conf マニュアルページのlogon script
パラメーターを参照のこと。 |
sambaProfilePath | ユーザーのプロファイルのパスを指定。この値は空、ローカル
な絶対パス、あるいはUNCパスが使える。詳細な情報は、smb.conf
マニュアルページのlogon pathパラメーター
を参照のこと。 |
sambaHomePath | ユーザーのホームディレクトリのパスを指定するsambaHomePath
プロパティ。この値は空でも良い。もしもsambaHomeDriveが
設定され、ドライブ名の場合、sambaHomePathはUNCパスである
必要がある。パスは\\server\share\directory
のようなネットワークUNCパスでなければならない。詳細な情報は、
smb.conf マニュアルページのlogon home
パラメーターを参照のこと。
|
Table 11.4. sambaSamAccountオブジェクトクラスの属性, Part B
sambaUserWorkstations | ユーザーのログイン可能な、カンマで分離されたマシンのリスト。 Sambaドメインメンバーに接続することを試みる時に問題が発生する かもしれない。なぜならば、ドメインメンバーがこのリストになく、 ドメインコントローラーはそれを拒否するため。この属性が省略された 場合、既定値は何の制限がないことを仮定する。 |
sambaSID | ユーザーのセキュリティ識別子(SID)。WindowsにおけるUNIX UID相当のもの。 |
sambaPrimaryGroupSID | ユーザーのプライマリグループのセキュリティ識別子(SID)。 |
sambaDomainName | ユーザーが属するドメイン。 |
これらのパラメーターの大多数はSambaがドメイン (どのようにSambaをPDCとして設定するかについての詳細がある ドメイン制御を参照)として振る舞う 時にのみ使われる。以下の4つの属性は、値が既定値でない場合にのみ sambaSamAccountエントリに格納される。
これらの属性は、値が既定値でない場合にのみsambaSamAccountに
格納される。例えば、MORIAがPDCとして設定され、そのsmb.conf
ファイル中でlogon home = \\%L\%u
が定義されているとする。“becky”という名前のユーザーが
がドメインにログオンした時にはlogon home
文字列は\\MORIA\beckyに展開される。もしも、smbHome属性が
“uid=becky,ou=People,dc=samba,dc=org”エントリ中に
存在するならば、この値が使われる。しかし、もしもこの属性が存在
しない場合、logon homeパラメーターの値が
その場所に使われる。Sambaは、値が既定値以外の何かである場合
(例えば\\MOBY\becky
)にのみ、属性値を
ディレクトリエントリに書き込む。
以下は、SambaSamAccountオブジェクトクラスの、動作するLDIFの使用例である。
dn: uid=guest2, ou=People,dc=quenya,dc=org sambaLMPassword: 878D8014606CDA29677A44EFA1353FC7 sambaPwdMustChange: 2147483647 sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-513 sambaNTPassword: 552902031BEDE9EFAAD3B435B51404EE sambaPwdLastSet: 1010179124 sambaLogonTime: 0 objectClass: sambaSamAccount uid: guest2 sambaKickoffTime: 2147483647 sambaAcctFlags: [UX ] sambaLogoffTime: 2147483647 sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5006 sambaPwdCanChange: 0
以下はsambaSamAccountとposixAccountオブジェクトクラスに対するLDIF エントリである:
dn: uid=gcarter, ou=People,dc=quenya,dc=org sambaLogonTime: 0 displayName: Gerald Carter sambaLMPassword: 552902031BEDE9EFAAD3B435B51404EE sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201 objectClass: posixAccount objectClass: sambaSamAccount sambaAcctFlags: [UX ] userPassword: {crypt}BpM2ej8Rkzogo uid: gcarter uidNumber: 9000 cn: Gerald Carter loginShell: /bin/bash logoffTime: 2147483647 gidNumber: 100 sambaKickoffTime: 2147483647 sambaPwdLastSet: 1010179230 sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004 homeDirectory: /home/moria/gcarter sambaPwdCanChange: 0 sambaPwdMustChange: 2147483647 sambaNTPassword: 878D8014606CDA29677A44EFA1353FC7
Samba-3以降のバージョンは、アカウントとして格納される非Samba(LDAP)パスワード を更新できる。pam_ldapを使う場合、UNIXとWindowsパスワードを同時に変更できる。
ldap passwd syncオプションでは、 設定可能なldap passwd sync の値にある値を使うことが出来る。
Table 11.5. 設定可能なldap passwd sync
の値
値 | 説明 |
---|---|
yes | ユーザーがパスワード変更時に
|
no |
|
only | LDAPパスワードとLDAPサーバーに他の フィールドについても更新を行う。このオプションはいくつかのLDAP サーバーと、LDAPサーバーがLDAP_EXOP_X_MODIFY_PASSWDをサポートする 時のみ有効である。 |
より詳細な情報は smb.conf
マニュアルページにある。
“Sambaをインストールしたが、UNIXアカウントを使ってログオンできない!”
現在のpassdb backendにユーザーが追加されて いるかを確認すること。詳細は アカウント管理ツールを読むこと。
明示的にauth methodsパラメーターを設定する場合、
guest
はエントリの最初の行に指定しなければならない
例えば、auth methods = guest samである。
Table of Contents
Samba-3からWindowsのグループSIDとUNIXのグループを関連づける新しいグループ
マッピング機能が利用できる。netツールに含まれる。groupmap
サブコマンドを、 関連づけの管理に使用する。
NTのグループとUNIXのシステムグループをマッピングするこの新しい機能では、
管理者が、どのNTドメイングループをMicrosoft Windowsクライアントに公開するか
を決定することができる。既定値(-1
)以外の値を持つ
UNIXのグループにマッピングするNT のグループのみが、ドメインユーザー及び
グループにアクセスするツールのグループ選択リストに含まれる。
Samba-3ではdomain admin group
パラメーターが削除されたので、
smb.conf
中にもはや指定してはならない。Samba-2.2.x中では、このパラメーターは
このパラメーターは、一覧表示されたユーザーに、 ワークステーション上でローカル管理
権限を与えるDomain Admins
Windowsグループのメンバーシップを
付与するのに使用されていた(既定値の設定では)。
Sambaでは、管理者がMicrosoft Windows NT4/200x グループアカウントを作成し、それらを 任意にUNIX/Linuxのグループアカウントと関連づけることができる。
グループアカウントは、Microsoft Windows NT4またはMicrosoft Windows 200x/XP Professional
のMMCツールを使用して管理することができる。これらのツールを使って自動的にUNIX/Linux
のシステムアカウントを作成するには、適切なスクリプトをsmb.conf
で提供する必要が
ある。それらのスクリプトが無い場合、winbindd
が動作している
限りは、これらのツールを使って作成されたSambaグループアカウントはsmb.conf
ファイル中のidmap uid/idmap gid
パラメーターで指定されているID範囲内でUNIX UID/GIDを割り当てられる。
どちらのケースでもwinbinddが動作していない場合は、ローカルで解決可能なグループ
のみが認識される。IDMAP: グループSIDからGIDへの解決
とIDMAP: GIDから対応するSIDへの解決を
参照のこと。IDMAPのグループマッピングの保存
で示すように、net groupmap
が、NTのSIDに対応するUNIXグループの
作成に使用される。
smb.conf
のグループインタフェーススクリプトが、直接UNIX/Linuxシステムツール
(shadowユーティリティ,groupadd
,groupdel
と
groupmod
)を呼び出した場合、UNIX/Linuxグループ名は、これらの
ツールが課す制約を受けることを、管理者は知っていなければならない。もし、
ツールが、大文字や空白文字を認めない場合、Microsoft Windows NT4/200x風の
Engineering Managers
というグループの作成は、同名のUNIX/Linux
グループの作成が試みられることになるが、それはもちろん失敗する。
このOSツールの制約に対しては幾つかの回避策がある。一つはOSの制約に合うUNIX/Linux システムグループ名を作成し、Sambaインターフェースの呼び出しには、UNIX/Linuxの グループID(GID)を返すようなスクリプトを使う方法である。これは、動的な回避策である。
もう一つの回避策は、手動でUNIX/Linuxグループを作成し、次に手動でSamba サーバーに
Microsoft Windows NT4/200xグループを作成し、そしてnet groupmap
ツールを使ってこの2つを互いに関連付けることである。
コンピュータにMicrosoft Windows NT4/200xをインストール
するとき、インストールプログラムは既定値のユーザーとグループを作成し、特に、
Administrators
グループの場合は、必須のシステムタスクを実行
するのに必要な権限をグループに付与する。例えば、ローカルマシンの日付や時間を変更
したり、ローカルマシン上の実行中のプロセスを止める(又は閉じる)ような権限である。
Administrator
ユーザーはAdministrators
グループのメンバーで、そのため、Administrators
グループの
権限を引き継ぐ。もし、joe
というユーザーが
Administrators
グループのメンバーとして作成された場合、
joe
はAdministrator
というユーザーと
全く同じ権限を持つ。
Microsoft Windows NT4/200x/XPマシンがドメインメンバーになる場合、
PDCの“Domain Admins”グループは、ワークステーションのローカル
Administrators
グループに追加される。
Domain Admins
グループのいずれのメンバーもワークステーション
にログオンすると、ローカルのAdministrators
グループの
権限を継承する。
以下のステップは、Samba PDCユーザーをDomain Admins
グループの
メンバーにする方法を説明する。
domadm
と呼ばれるUNIXグループを作成(通常/etc/group
の中に)。
このグループに“Administrators”にならなければならないユーザーを
追加。たとえば、joe, john
とmary
administratorsにしたいならば、/etc/group
のエントリは
下記のようになる:
domadm:x:502:joe,john,mary
以下のコマンドを実行して、“Domain Admins”グループをdomadm グループにマップする:
root#
net groupmap add ntgroup="Domain Admins" unixgroup=domadm rid=512 type=d
“Domain Admins”の両側の引用符は、グループ名に空白があるために 必要である。また、イコール記号(=)の前後に空白を入れないこと。
これでjoe, john
とmary
はdomain administratorsになった。
任意のUNIXグループを任意のWindows NT4/200xグループにマッピングしたり、UNIX グループをWindowsドメイングループにすることが可能である。例えば、あるUNIXグループ (例: acct)をドメインメンバーマシンのローカルファイルやプリンターのACLに含めたい場合、 以下のコマンドをSamba PDC上で実行して、そのグループをドメイングループにする:
root#
net groupmap add rid=1000 ntgroup="Accounting" unixgroup=acct type=d
ntgroup
の値は、コマンドのデリミタとして解釈されてしまうことを
防ぐために、空白が入っている場合には引用符で囲まなければならない。
RIDパラメーターは通常1000から始まる符号なしの32ビット整数である。しかし、このRIDは ユーザーに割り当てられるRIDと重複してはならない。これを検証する方法は、使用して いるpassdbバックエンドによって異なる。このツールの今後のバージョンでは自動検証が 可能になるかもしれまないが、現行では、使用者が自分でやらなければならない。
Windowsは同じ名前のユーザーとグループアカウントを許可しない。これは、プライベート グループを使っているすべてのサイトに重大な影響がある。プライベートグループ アカウントは、ユーザーがおのおの固有のグループアカウントを持つという管理上の 設定である。Red Hat Linuxやいくつかの自由なLinuxディストリビューションでは、 既定値でプライベートグループを作成する。
UNIX/LinuxグループアカウントがWindowsグループアカウントにマップされた場合、 すべての競合は、任意のユーザーアカウント名にWindowsドメイングループ名が オーバーラップしないことを保証することで防げる。
nested groups
として知られているこの機能は、Samba-3.0.3
で初めて追加された。
Windows NT 3.10リリース以降のすべてのMicrosoft Windows製品は、ネストされた グループをサポートしている。セキュリティ管理をとても簡単にするので、多くの Windowsネットワーク管理者はこの機能に依存している。
ネストされたグループアーキテクチャは、日々のユーザーとグループメンバー管理をドメイン セキュリティデータベース上で実行されるべきという理由でデザインされた。グループ セキュリティの応用は、ローカルグループのみを使うドメインメンバーサーバー上で実装 されるべきである。ドメインメンバーサーバー上で、すべてのファイルシステムセキュリティ 制御は、ドメイングローバルグループとドメイングローバルユーザーを含むローカル グループの使用を制限する。
この取り決めの利便性は何か、という疑問があるかもしれない。Windowsネットワーク アーキテクチャの深い闇を知っている人にとって、答えは明確である。20万ものファイル があり、各ファイルは個別のドメインユーザーとドメイングループに設定されているサーバー について考えてみよう。ファイルサーバーを持つ会社が別の会社を買い、その結果、サーバー を別の場所に移動し、別のドメインのメンバーにするとする。誰がすべてのファイルと ディスクを所有すると思うか? 答えは「不明なアカウント」である。
ファイル所有権の混乱を解決することは、すべてのファイルとディレクトリアクセス
制御をコントロールするためにローカルグループを用いて簡単に避けられることが
できる面白くない管理業務である。この場合、ローカルグループのメンバーのみが
失われる。記憶サブシステム中のファイルとディレクトリは引き続きローカル
グループによって所有される。同じことはそれらに対するすべてのACLについても
存在する。サーバーがメンバーとなった新しいドメイン中のドメイングローバルグループ
のための適当なエントリをもつローカルグループ内の
不明なアカウント
メンバーシップエントリを削除するのは
管理的により簡単である。
ネストされたグループを使用する、もう一つの突出した例は、ドメインメンバーワーク
ステーションとサーバーで管理特権の実装を伴う。管理特権は各ドメインメンバーマシンの
ビルトインAdministrators
ローカルグループのすべてのメンバーに
与えられる。すべてのdomain administratorsがメンバーサーバーまたはワークステーション
に対してとドメインの参加に対して完全な権限を持つようにするには、
Domain Admins
グループをローカルのAdministratorsグループに
追加する。そのため、Domain Adminsグループのメンバーとしてドメインにログオンする
誰もが、各ドメインメンバー上のローカル管理特権をも持つ。
UNIX/Linuxはネストされたグループという概念を持たないので、Sambaは長い間それを
サポートしてこなかった。問題は、/etc/group
中の追加グループ
のメンバーとしてUNIXグループを入力しなければならないことである。これは、今実装
されているUNIXファイルシステムセキュリティモデルのデザインの要求でないために
動作しない。Samba-2.2以降、winbindは、メンバーであるSambaサーバーのドメイン
コントローラーからのユーザーとグループ情報をオンデマンドで
/etc/group
に提供出来る。
実際、Sambaは動的なlibnss_winbind
メカニズム経由で
/etc/group
データを補完する。Samba-3.0.3から、この機能は
Windowsが行うのと同じ方式でローカルグループを提供するために使われる。これは、
アクセス時にその場でローカルグループに展開されることによって動作する。たとえば、
ドメインのDomain Users
グループがローカルグループ
demo
のメンバーになるというようなことである。Sambaが
ローカル(alias)グループdemo
のメンバーであることを解決する
必要がある時はいつも、winbindはDomain Usersグループのdemoメンバーについて
ドメインコントローラーに問い合わせる。定義によって、UNIX/Linuxグループ
demo
のメンバーであるように見せかけることが出来る、ユーザー
オブジェクトのみを含むことが出来る。
ネストされたグループを有効にするために、winbindd
はNSS winbind
と一緒に使わなければならない。ローカルグループの作成と管理はWindowsのドメイン
ユーザーマネージャかそれのSambaでの相当品、net rpc group
ユーティリティ経由が最適である。ローカルグループdemo
の作成は以下のように行う:
root#
net rpc group add demo -L -Uroot%not24get
ここで、-Lスイッチはローカルグループ作成を意味する。適切なユーザーかルート権限で
正しいホストにアクセスするために、-Sと-Uスイッチの追加が必要かもしれない。
グループメンバーの追加と削除はnet rpc group
コマンドの
addmem
とdelmem
サブコマンド経由で
行える。たとえば、ローカルグループdemo
に
“DOM\Domain Users”を追加するのは以下のように行う:
net rpc group addmem demo "DOM\Domain Users"
これら2つのステップを完了し、getent group demo
を実行すると、
グループdemo
のメンバーとしてグローバルな
Domain Users
グループのメンバーとしてdemoを表示する。
これはまた、任意のローカルまたはドメインユーザーでも動作する。ドメインDOMが
他のドメインを信頼している場合、信頼されたドメインに、
demo
のメンバーとしてグローバルユーザーとグループを追加すること
も可能である。demo
グループに追加されたグループのメンバーで
ある他のドメインからのユーザーはローカルドメインユーザーが持つのと同じアクセス許可を
持つことになる。
管理者権限は以下の二つの用途に対して必要である:
Samba-3のドメインコントローラー、ドメインメンバーサーバー及びクライアントのため。
Windowsのドメインメンバーワークステーション管理のため。
Samba 3.0.10までのバージョンは、Windowsドメインメンバークライアントマシンから システム管理作業のために必要である権利と特権を割り当てる機能は提供しない。その ため、ユーザーの追加、削除とユーザーとグループ情報の変更と、ワークステーションの ドメインメンバーシップ管理のような管理作業はroot以外のどのようなアカウントでも 扱える。
Samba-3.0.11から、管理作業を非root(すなわち、Microsoft Windows Administratorと 同等以外のアカウント)に委譲できる新しい特権管理インタフェースが含まれるように なった(ユーザーの権限と権利を参照)。
Windowsドメインメンバーワークステーション上の管理作業はDomain Admins
グループのメンバーの誰かによって行える。このグループは任意の適切なUNIXグループに
マップできる。
ユーザーの追加削除のようなUNIX/Linux上の管理作業はroot
と
同等の権限が必要である。Samba のドメインに対するWindowsクライアントの追加は、
Windows クライアントに対するユーザーアカウントの追加が含まれる。
多くのUNIX管理者がSamba Teamに対してroot
の権限を持たなくても
Windowsクライアントの追加、ユーザーの追加、変更、削除ができるようにしてほしいという
要望を寄せ続けている。このような要望はUNIXシステムの基本的なセキュリティの観念と
接触するものある。
root
レベルの権限を与えずにUNIX/Linuxシステムに対してアクセス
する安全な方法はない。root
権限は、ドメインに
root
ユーザーでログインするか、ある特定のユーザーを、
/etc/passwd
データベースの中にUID=0とすることで可能となる。
それらの ユーザーは、NT4 のドメインユーザーマネージャやドメインサーバーマネージャ
などのツールを使用してユーザーやグループに加えドメインメンバーサーバーやクライアント
アカウントの管理ができる。また、このレベルの権限が、共有レベルのACL管理には
必要である。
インストール直後、Windows NT4/200x/XPは特定のユーザー、グループ及び別名のエントリ
が事前に設定される。それらはよく知られている相対識別子(RID)を持つ。これらは
運用の継続的な整合性のために維持しなければならない。Sambaは必須のドメイン
グループを持たなければならず、それらのグループは適切なRID値を必要とするSamba-3
がtdbsam
を使用するよう設定されていると、必須のドメイン
グループは自動的に作成される。その既定値のNTグループを作成(準備)するのはLDAP
管理者の責任である。
必須のドメイングループには良く知られているRIDを割り当てなければならない。既定値の ユーザー、グループ、別名とRIDは よく知られているユーザーのRID既定値を参照のこと。
他にも必要なドメイングループを作成することは問題ありませんが、必須のドメイン グループ(良く知られているもの)が作成済みで、既定値のRIDが割り当てられている ことを確認すること。作成する他のグループには任意のRIDを割り当てることができる。
各ドメイングループをUNIXシステムグループにマッピングすること。それが、これらの グループをNTドメイングループとして使用できる唯一の方法である。
Table 12.1. よく知られているユーザーのRID既定値
よく知られているエントリ | RID | タイプ | 必須 |
---|---|---|---|
Domain Administrator | 500 | User | No |
Domain Guest | 501 | User | No |
Domain KRBTGT | 502 | User | No |
Domain Admins | 512 | Group | Yes |
Domain Users | 513 | Group | Yes |
Domain Guests | 514 | Group | Yes |
Domain Computers | 515 | Group | No |
Domain Controllers | 516 | Group | No |
Domain Certificate Admins | 517 | Group | No |
Domain Schema Admins | 518 | Group | No |
Domain Enterprise Admins | 519 | Group | No |
Domain Policy Admins | 520 | Group | No |
Builtin Admins | 544 | Alias | No |
Builtin users | 545 | Alias | No |
Builtin Guests | 546 | Alias | No |
Builtin Power Users | 547 | Alias | No |
Builtin Account Operators | 548 | Alias | No |
Builtin System Operators | 549 | Alias | No |
Builtin Print Operators | 550 | Alias | No |
Builtin Backup Operators | 551 | Alias | No |
Builtin Replicator | 552 | Alias | No |
Builtin RAS Servers | 553 | Alias | No |
net groupmap list
を実行することでマッピングデータ
ベース中の種々のグループを表示出来る。以下が例である:
root#
net groupmap list
Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin Domain Users (S-1-5-21-2547222302-1596225915-2414751004-513) -> domuser Domain Guests (S-1-5-21-2547222302-1596225915-2414751004-514) -> domguest
net groupmap
の完全な詳細は、net(8)のマニュアルを参照のこと。
誰もがツールを必要とする。自分のツールを作ることが好きな人もいれば、既成のツール (汎用に誰かが作成したもの)を好む人もいる。
Sambaのグループインタフェースで使用するグループ名を作成するスクリプトは
smbgrpadd.shで提供されている。
このスクリプトは一時的なエントリを/etc/group
ファイルに追加し、指定された名前に改名する。これは、いくつかの
バージョンのgroupadd
ツールに存在する、OS管理ツールの
制限を避ける方法の例である。
Example 12.1. smbgrpadd.sh
#!/bin/bash # 通常のgroupaddツールを使ってのグループ追加。 groupadd smbtmpgrp00 thegid=`cat /etc/group | grep ^smbtmpgrp00 | cut -d ":" -f3` # 次にMicrosoft Windowsネットワーク用に使いたい名前に変更。 cp /etc/group /etc/group.bak cat /etc/group.bak | sed "s/^smbtmpgrp00/$1/g" > /etc/group rm /etc/group.bak # 通常のようにGIDを返す。 echo $thegid exit 0
グループ追加スクリプトのためのsmb.conf
エントリの設定
中に示している上記のスクリプトのためのsmb.conf
エントリは、どのように動くかを
デモする。
上記の例では、ntadmin
と呼ばれるUNIX/Linuxグループを作成した。
このスクリプトで、Orks
, Elves
と
Gnomes
という追加のグループも作成することにする。
後でマッピングデータベースを再作成する必要がある場合に備え、このシェルスクリプト
を保存することを推奨する。便宜上、initGroups.sh
という
ファイル名で保存する。このスクリプトは
intGroups.shで提供されている。
Example 12.3. Script to Set Group Mapping
#!/bin/bash net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin rid=512 type=d net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=d net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d groupadd Orks groupadd Elves groupadd Gnomes net groupmap add ntgroup="Orks" unixgroup=Orks type=d net groupmap add ntgroup="Elves" unixgroup=Elves type=d net groupmap add ntgroup="Gnomes" unixgroup=Gnomes type=d
もちろん、必要に合わせて管理者がこれを編集することを想定している。
net groupmap
ツールの使用方法の詳細についてはマニュアル
ページを参照のこと。
Sambaのバージョン3.0.23未満では、
Domain Admins, Domain Users
とDomain Guests
Windowsグループに対する既定値のグループマッピングを自動的に生成する。しかし、
UNIX GIDへのマップは行わない。これは管理者の混乱と障害を引き起こす。Samba-3.0.23
以降はこの異常は修正された。そのため、Windowsグループは、手動かつ明示的にSamba
管理者によって有効なUNIX GIDへのマップの作成とマッピングを行わなければならない。
この時点で、油断していると管理者はいろいろな細かいことにびっくりされられることになる。 現実問題として、自動の制御スクリプトの全ステップを本番環境に移す前には、注意深く手動で テストしなければならない。
これはSambaインタフェーススクリプトがsmb.conf
ファイル中の
add group scriptとして直接
groupadd
呼んだ時によくある問題である。
もっともよくある失敗の原因は、名前に大文字かつまたはスペースを含む Microsoft Windows グループアカウントを追加しようとしたということである。
これには 3 つの回避策がある。一つ目は、UNIX/Linuxのgroupadd
システムツールの制約に沿うグループ名のみを使用することである。二つ目は、
この章で先に言及したスクリプトを使用することである。三つ目は、
Microsoft Windowsグループ名に代わるUNIX/Linuxグループアカウントを手動で作成し、
上で説明した手順でそのグループをMicrosoft Windows グループにマッピングする
という方法である。
“ domain usersをPower Usersグループに追加するにはどうすればいいですか? ”
Power Usersグループは各Windows 200x/XP Professionalワークステーションの ローカルグループである。Domain Usersグループは自動でPower Usersグループに 追加することはできない。ローカルマシンにadministrator としてローカルワークステーションにログオンすることで、各ワークステーション でこの作業を行わなければならず、その後以下の手続きを行う:
Click
タブをクリック。
ボタンをクリック。
グループ
をクリック。
Power Users
をダブルクリック。この作業後、ローカル
マシンのPower Users
グループにユーザーとグループを
追加するパネルが起動する。
ボタンをクリック。
Domain Users
グループに追加するドメインを選択。
Domain Users
グループをダブルクリック。
DOMAIN\UserName
を入力することを忘れないこと。
すなわち、ドメインMIDEARTH
とユーザー
root
をMIDEARTH\root
として入力する。
Table of Contents
net
コマンドはSamba-3における新しい機能の1つで、共通作業のために、
多くの必要なリモート管理操作用の便利なツールを提供する試みである。net
は自由度が高いデザインで、スクリプト制御アプリケーションのためと同様にコマンド行操作
でも使うように出来ている。
当初は同じ名前のMicrosoft Windows コマンドの模倣を狙って作られたが、net
は、Sambaネットワーク管理者の道具箱の基本的な部分になる、非常に強力なツールに変貌した。
Samba Teamは、smbgroupedit
とrpcclient
のような
ツールも提供していて、それらは本当に役に立つ能力がnet
コマンドに集約
された。smbgroupedit
コマンドは、いくつかの機能のみが
rpcclient
に集約された間、net
コマンドに完全に移植された。
それらのユーティリティや機能に対する古いリファレンスを見つけた場合、それ以外を探す前に、
net
コマンドを見るべきである。
Samba-3管理者は、そうすることが、自ら招いた痛み、苦しみと自暴自棄を科すことをほとんど 確実に引き起こすので、この章を取り繕うことができない。
Samba-3サーバーのインストールに伴う作業は、スタンドアロンかドメインメンバーの どちらも、さらにドメインコントローラー(PDCまたはBDC)は管理者権限の作成を必要と するところから始まる。もちろん、ユーザーとグループアカウントの作成は、スタンド アロンサーバーとPDC両者において必須である。BDCまたはドメインメンバーサーバー(DMS) においては、ドメインユーザーとグループアカウントは中央のドメイン認証バック エンドから得られる。
インストールされているサーバーのタイプに関係なく、ローカルUNIXグループはWindowsの
ネットワークにおけるドメイングローバルグループアカウントにマップされねばならない。
なぜだろうか?それは、Sambaは常時、伝統的なUNIXのUIDとGID制御によってホスト
サーバーのリソースのアクセスを制限するからである。これは、ドメイングローバル
グループのメンバーであるドメインユーザーは、Sambaがホスティングしているサーバーの
ローカルなUIDとGIDをベースとしたアクセス権が与えられるようにするために、
ローカルグループはドメイングローバルグループにマップされなければならない。
このようなマッピングはnet
コマンドを使うことで実装される。
メンバー(PDC、BDCあるいはDMS)として動作しているSamba-3サーバーがホスティングしている
UNIXシステムは、ドメイン認証データベース(かあるいはディレクトリ)中にマシン信頼
アカウントを持たねばならない。そのようなセキュリティ(あるいは信頼)アカウントの
作成も、net
コマンドを使うことよって扱える。
net
コマンドを使うことで、ドメイン間信頼関係をも確立でき、
また、ユーザー管理、グループ管理、共有とプリンター管理、ファイルとプリンターの
マイグレーション、SIDの管理などのような、有り余るほどの典型的な管理作業も
できる。
全体の構成は今明確にすべきである:net
はSamba-3の動作において
重要な役割を演じる。その役割は継続して開発されている。この章に含まれているもの
は、その重要性の証拠であり、それは、完全にオンラインUNIXマニュアル中でその
使用をカバーすることが賢明であるとは、もはや考えられない点において、複雑に成長
してきた。
net
の基本的な動作はここに文書化されている。この文書は完璧
ではなく、不完全である。WindowsサーバーからSambaサーバーへの移行について最も着目
しているので、分散コンピューティング環境のリモートプロシジャーコール(DCE RPC)
モードの操作について強調している。Active Directoryドメインのメンバーであるサーバーに
対して使用されるとき、ADSモード操作を使うことは望ましい(そして、それはしばしば
必要である)。net
は両方ともサポートするが、すべての操作に
対してではない。モードが指定されない多くの操作では、net
は
自動的にads
, rpc
と
rap
モードにフォールバックする。このユーティリティの
能力についてのより包括的な概要はマニュアルページを参照のこと。
初めに、この章の主要な注目点は、Sambaによってサポートされている
net rpc
ファミリの動作の使用方法である。それらの大半は、
Active Directoryに接続したときに使われるnet ads
モードでも
サポートされる。net rap
動作モードもそれらの操作のいくつかで
サポートされる。RAPプロトコルはIBM OS/2といくつかの初期のSMBサーバーによって
使われる。
Sambaのnet
ツールはコマンドラインで完結するための、すべての
共通な管理作業が出来る十分な能力を実装している。このセクションでは、必須の
ユーザーとグループ管理機能のそれぞれについて説明している。
Samba-3は2種類のグループを認識する。それは、ドメイングループ とローカルグループである。ドメイングループは(メンバーとして) ドメインユーザーアカウントのみを含むことは出来る。ローカルグループはローカル グループ、ドメインユーザーとメンバーとしてのドメイングループをを含むことが出来る。
ローカルグループの目的は、そのグループアカウントに対して、通常のUNIX/Linux グループのようにファイルのアクセス権を 設定することであり、また、Windows ファイルサーバーを再配置しても継続的である。
SambaはWindowsクライアントにファイルと印刷サービスを提供する。Windows環境に 対して有効にしたファイルシステムリソースは、必要に応じてWindowsネットワーク 環境と互換の方式で提供しなければならない。UNIXグループはUNIX OSとそのファイル システム内で、操作の必要で提供するために要求に応じて作成および削除される。
Windows環境に対して有効にするために、Sambaは、Windows(あるいはドメイン)グループ と呼ばれる論理的なエントリに、UNIXグループをマップされることが出来る機能を持つ。 Sambaはローカルとグローバルと言う2つのタイプのWindowsグループをサポートする。 グローバルグループはメンバーとグローバルユーザーを含むことが出来る。このメンバーシップは 通常のUNIX流儀に影響されるが、UNIXユーザーをUNIXグループに追加する。Windowsユーザー アカウントはユーザーのSambaSAMAccount(論理エントリ)とUNIXユーザーアカウントとの マッピングから成り立つ。そのため、UNIXユーザーはWindowsユーザーにマップされ(すなわち、 Windowsユーザーアカウントとパスワードが与えられる)、そのユーザーに属するUNIX グループはWindowsグループアカウントにマップされる。この結果は、Windowsアカウント 環境においてそのユーザーが、UNIXグループメンバーシップであるという理由で、Windows グループアカウントのメンバーでもあるということである。
Windowsグループ管理を扱う以下の項では、Windowsグループアカウントとそのメンバーの 間の関係について、それぞれのWindowsグループアカウントの関係をデモする。これは、 論理マッピングが作成されるとすぐに、どのように自動的にUNIXグループメンバーをWindows グループメンバーシップに渡すかを表示する。
Windowsグループアカウントを追加する前に、現在有効なグループは以下のようにして表示できる:
root#
net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers
“SupportEngrs”というWindowsグループアカウントは、以下のコマンドを 実行することで追加できる:
root#
net rpc group add "SupportEngrs" -Uroot%not24get
以下のコマンドを実行することで、新しいグループアカウント追加の結果が有効になって いることが検証できる:
root#
net rpc group list -Uroot%not24get
Password:
Domain Admins
Domain Users
Domain Guests
Print Operators
Backup Operators
Replicator
Domain Computers
Engineers
SupportEngrs
以下はPOSIX(UNIX/Linuxシステムアカウント)グループが、 add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g" インタフェーススクリプトを呼び出すことによって作成されたことを表示する:
root#
getent group
...
Domain Admins:x:512:root
Domain Users:x:513:jht,lct,ajt,met
Domain Guests:x:514:
Print Operators:x:550:
Backup Operators:x:551:
Replicator:x:552:
Domain Computers:x:553:
Engineers:x:1002:jht
SupportEngrs:x:1003:
以下は、グループアカウントを追加するnet
の使用で、Windows
グループアカウントのために作られたPOSIXグループの即時的なマッピング中での結果を示す:
root#
net groupmap list
Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users
Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests
Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators
Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators
Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator
Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers
Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers
SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
Windowsグループは、SambaサーバーをホスティングしているOSに適した方法での首尾一貫 した方法で主張できるファイルシステムのアクセス制御が出来るように、UNIXシステム (POSIX)グループにマップされる必要がある。
SambaサーバーをホスティングしているUNIX/Linuxサーバーのファイルシステムで、すべての
ファイルシステム(ファイルとディレクトリ)アクセス制御はUID/GID識別の組を使って
実装される。SambaはUNIXファイルシステムの仕組みに優先したり、置き換えることは
しない。これは、ファイルシステムにアクセスするすべてのWindowsネットワーク操作は、
Windowsユーザーから特定のUNIX/Linuxグループアカウントにマップするメカニズムを
提供する。ユーザーアカウントはローカルに知られているUIDにもマップする必要がある。
net
コマンドはここでは任意のRPC機能は呼び出さないが、passdbに
直接アクセスすることに注意。
SambaはDomain Admins, Domain Users
と
Domain Guests
グローバルグループの既定値のマッピングに
依存する。追加のグループはサンプルで与えられた中でのように追加できる。存在する
UNIXグループアカウントをWindowsグループにマップすることが必要なときがある。
この操作は実際Windowsグループアカウントをマップ生成の結果として作成する。
add
、modify
とdelete
を含む操作が許可される。それぞれの操作の例はここで示される。
Samba-3.0.23で始まるWindowsドメイングループは明示的に作成する必要がある。既定値 では、すべてのUNIXグループはWindowsローカルグループとしてWindowsネットワーク に対して公開される。
存在するUNIXグループは以下の例のようにして存在するWindowsグループにマップされる:
root#
net groupmap modify ntgroup="Domain Users" unixgroup=users
存在するUNIXグループは以下の例のようにして新しいWindowsグループにマップされる:
root#
net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d
サポートされているマッピングタイプは'd'(ドメイングローバル)と'l'(ドメインローカル) である。Windowsグループは削除でき、新しいWindowsグループは以下のコマンドでUNIX グループにマップ出来る:
root#
net groupmap delete ntgroup=Engineersroot#
net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d
削除と追加操作はWindowsグループかドメイングループとして知られている論理エントリ のみに影響する。操作は、UNIXシステムグループの削除も作成もしないので、UNIX システムグループには影響しない。UNIXグループからWindowsグループへのマッピングは、 ドメインメンバークライアント上(ワークステーションとサーバー)のファイルとフォルダーが、 ドメインユーザーとグループに対してドメイン全体のアクセス制御を得ることが出来る ようにするために、WindowsグループとしてWindowsグループを有効にさせる。
domain(グローバル)
とlocal
という
二種類のWindowsグループか作成できる。前者の例では、作成されたWindowsグループは
domain
かグローバルタイプである。以下のコマンドでは、
local
タイプのWindowsグループを作成する。
root#
net groupmap add ntgroup=Pixies unixgroup=pixies type=l
サポートされているマッピングタイプは'd' (ドメイングローバル)と 'l' (ドメイン ローカル)で、Samba中でのドメインローカルグループは個別のSambaサーバーに対する ローカルなものとして扱われる。ローカルグループは、複数ネストされたグループの サポートを有効にするためにSambaで使うことができる。
root#
net rpc group delete SupportEngineers -Uroot%not24get
削除の検証は有効である。同じコマンドは以下で示されるように実行できる。
このコマンドはマニュアルページには記述がない。ソースコード上では実装されているが、 現時点では動作しない。ソースコード上から得られた文書例は、どのようにそれが 動くかを示す。これがいつ修正されるかを、今後のリリースにおけるリリースノート で確認すること(訳注:3.4.0でもマニュアルに記載はない)。
時々グループアカウントの改名が必要なときがある。良い管理者は、この単純な要求が 無視されるならば、何人かのマネージャの要求がどのくらい痛ましくなるかを知っている。 以下のコマンドは、どのようにWindowsグループ“SupportEngrs”が “CustomerSupport”に改名できるかを示す:
root#
net rpc group rename SupportEngrs \
CustomerSupport -Uroot%not24get
3つの操作をグループメンバーシップに関して行うことが出来る。それは、(1)Windows ユーザーをWindowsグループに追加する、(2)WindowsグループからWindowsユーザーを削除する、 (3)Windowsグループに属するWindowsユーザーを表示する である。
混乱を防ぐため、何らかの変更を行う前に、グループメンバーシップを確認することは
意味がある。getent group
はUNIX/Linuxのグループメンバーシップを
表示する。UNIX/Linuxグループメンバーはnet groupmap
コマンド
(“グループのマッピング: Microsoft Windows と UNIX”を参照)で、マップされたWindowsグループのメンバー
としても見ることができる。以下のUNIX/Linuxメンバーシップは、ajt
というユーザーがEngineers
というUNIX/Linuxのグループのメンバー
であることを示している。
root#
getent group
...
Domain Admins:x:512:root
Domain Users:x:513:jht,lct,ajt,met,vlendecke
Domain Guests:x:514:
Print Operators:x:550:
Backup Operators:x:551:
Replicator:x:552:
Domain Computers:x:553:
Engineers:x:1000:jht,ajt
WindowsグループにマップされたUNIX/Linuxのグループは以下のようになる:
root#
net groupmap list
Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins
Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users
Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests
Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators
Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators
Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator
Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers
Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers
与えられたajt
というユーザーは、すでにUNIX/Linuxグループの
メンバーで、グループマッピング経由、Windowsグループのメンバーで、このアカウントを
再度追加する試みは失敗する。これのデモは以下の通り:
root#
net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
これは、UNIX/LinuxグループとWindowsグループの間のグループマッピングは有効でかつ 透過的であることを示している。
ユーザーajt
を、net rpc group
ユーティリティ
を使って追加することを許可するために、このアカウントは最初に削除されねばならない。
削除とその確認は以下のようになる:
root#
net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24getroot#
getent group Engineers Engineers:x:1000:jhtroot#
net rpc group members Engineers -Uroot%not24get MIDEARTH\jht
この例2つの中で、UNIX/Linuxシステムレベルで、グループはもはやajt
をメンバーとしてはいない。上記は又Windowsグループメンバーシップの場合も示している。
net rpc group
ユーティリティを使ってアカウントは再度追加される:
root#
net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24getroot#
getent group Engineers Engineers:x:1000:jht,ajtroot#
net rpc group members Engineers -Uroot%not24get MIDEARTH\jht MIDEARTH\ajt
この例では、WindowsのDomain Users
アカウントのメンバーは
net rpc group
ユーティリティを使って検証される。この
UNIX/Linuxグループの内容は4つ前のパラグラフで示されていることに注意。
Windows(ドメイン)グループメンバーシップは以下のようになる:
root#
net rpc group members "Domain Users" -Uroot%not24get
MIDEARTH\jht
MIDEARTH\lct
MIDEARTH\ajt
MIDEARTH\met
MIDEARTH\vlendecke
この特別な例は、Windowsグループ名が、大文字小文字を区別しない流儀で (Microsoft Windowsと同じ)Sambaによって扱われることを示す:
root#
net rpc group members "DomAiN USerS" -Uroot%not24get
MIDEARTH\jht
MIDEARTH\lct
MIDEARTH\ajt
MIDEARTH\met
MIDEARTH\vlendecke
単純にDomain Users
の代わりに
MIDEARTH\Domain Users
という形でグループ名を指定しても
失敗する。net rpc group の既定値の動作はローカルマシンへコマンドの動作を
行うからである。Windowsグループはマシンに対してローカルなように扱われる。
もしも他のマシンに対して問い合わせが必要ならば、その名前は、
net
コマンドの-S servername
パラメーターを使って指定する。
ドメインユーザーとドメイングループのメンバーである(含む)ローカルグループを作成する
ことはWindows(と現在はSambaも)で可能である。demo
という
ローカルグループは以下のようにして作成できる:
root#
net rpc group add demo -L -S MORDON -Uroot%not24get
ここで、-L スイッチはローカルグループ作成を意味する。特定のサーバーに対しての 動作を行う場合は、 -S 引数を使う。-U引数はマシン上で適切な権限と権利を持つ ユーザーを指定するのに使う。
グループメンバーの追加と削除はnet rpc group
コマンドの
addmem
とdelmem
サブコマンドを使う
ことで行える。たとえば、ローカルグループdemo
に対して
“DOM\Domain Users”を追加するには以下のように行う:
root#
net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get
以下のようにして、ネストされたグループのメンバーを表示することが出来る:
root#
net rpc group members demo -Uroot%not24get
DOM\Domain Users
DOM\Engineers
DOM\jamesf
DOM\jht
ネストされたグループメンバーは以下のようにして削除出来る:
root#
net rpc group delmem demo "DOM\jht" -Uroot%not24get
Windowsネットワーク管理者はしばしばSambaメーリングリストに、個々のワーク ステーション上ですべての人に管理者権限を許可することが可能かと言うことを 質問してくる。これは、もちろんとても悪い習慣ではあるが、一般的にユーザーの不満を 防ぐために行われる。個々では、どのようにSamba PDCまたはBDCからリモートでそれが 出来るかを示す:
root#
net rpc group addmem "Administrators" "Domain Users" \
-S WINPC032 -Uadministrator%secret
これはスクリプト化出来、そのためにWindowsワークステーションからドメインに ログオンするユーザーとして実行できる。どのようにそれが行われるかの簡単な例を 以下に示す。
Procedure 13.1. ワークステーションの Power Usersグループへの自動的なユーザーの追加
Example 13.1. ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト
#!/bin/bash /usr/bin/net rpc group addmem "Power Users" "DOMAIN_NAME\$1" \ -UAdministrator%secret -S $2 exit 0
“ワークステーションのPower UsersグループにDomain Users を自動で追加するスクリプト”で示されているスクリプトを
作成し、autopoweruser.sh
という名前で
ディレクトリ/etc/samba/scripts
中に配置する。
ログオンプロセスの一部として実行できるようにスクリプトにパーを設定する:
root#
chown root:root /etc/samba/autopoweruser.shroot#
chmod 755 /etc/samba/autopoweruser.sh
Netlogonのsmb.confファイルでの例
で示されるようなNETLOGON
セクションが含むパラメーター
のようにsmb.conf
ファイルを変更する。
すべてのWindowsワークステーション管理者アカウントが、 Netlogonのsmb.confファイルでの例 にあるようなスクリプト中で使われるのと同じパスワードを持つようにする。
このスクリプトはユーザーがネットワークにログオンする時には毎回実行される。 そのため、すべてのユーザーはローカルWindowsワークステーションの管理権限を 持つ。これはもちろんグループを使って割り当てることが出来、その場合、 この手続きの使用のためには微少な修正ですむ。この方法の使用のための修正 点の肝心なところは、すべてのユーザーがワークステーション上で適切な権限を 持つことを保証することである。
すべてのWindowsネットワークユーザーアカウントはUNIX/Linuxユーザーアカウントに変換
されねばならない。実際には、UNIX/LinuxのSambaサーバーは、アカウント情報の内のUID
のみを必要とする。UIDは、システム(POSIX)アカウントか、Windowsユーザーアカウントに
よって使われるために割り当てられる目的で予約されるUID番号の事前割当範囲(レンジ)
から取得される。この場合、UID事前割当範囲(訳注:pool)の場合、特定のユーザーに
対するUIDはwinbindd
によって割り当てられる。
ここは、異なった名前を持つUNIXアカウントにWindowsユーザーアカウントをマッピング
する重要な方法であusername mapインタフェース機能を
議論するのにふさわしい場所ではない。この機能についての詳細はsmb.conf
ファイルの
マニュアルページを参照のこと。
net
経由(詳細はマニュアルページ)でのユーザーの追加は以下の通り:
net [<method>] user ADD <name> [-c container] [-F user flags] \ [misc. options] [targets]
ユーザーアカウントのパスワードは以下の方法で設定できる:
net rpc password <username> [<password>] -Uadmin_username%admin_pass
root#
net rpc user add jacko -S FRODO -Uroot%not24get
Added user jacko
アカウントのパスワードは以下の方法で追加できる(すべて同じ操作を示す):
root#
net rpc password jacko f4sth0rse -S FRODO -Uroot%not24getroot#
net rpc user password jacko f4sth0rse \ -S FRODO -Uroot%not24get
ユーザーアカウントの削除方法は以下の通り:
net [<method>] user DELETE <name> [misc. options] [targets]
root#
net rpc user delete jacko -Uroot%not24get
Deleted user account
2の基本的なユーザーアカウント操作が定常的に使われる:パスワード変更とどのグループに ユーザーが所属しているかの問い合わせである。パスワード変更操作は “ユーザーアカウントの追加”の通り。
Windowsグループのメンバーシップの問い合わせ能力は基本的である。以下では、リモート サーバーが、どのグループにユーザーが属しているかを調べることが出来るかを示す:
root#
net rpc user info jacko -S SAURON -Uroot%not24get
net rpc user info jacko -S SAURON -Uroot%not24get
Domain Users
Domain Admins
Engineers
TorridGroup
BOP Shop
Emergency Services
古いユーザー名から新しいユーザー名へのユーザーアカウントの改名も可能である。ただし、この操作はSambaサーバーに対しては動作しないことに注意。しかし、ユーザー名の改名はWindowsサーバーでは可能である。
ある条件下で、ユーザーのWindowsにおけるログオン名はSambaサーバー上で持つユーザーの
ログインIDと異なることは避けられない。Sambaサーバー上で、Windowsユーザー名を
異なったUNIX/Linuxユーザー名にマップできる特別なファイルを作ることが出来る。
smb.conf
ファイルも、[global]
セクションで以下の
パラメーターを含むように変更しなければならない。
username map = /etc/samba/smbusers
/etc/samba/smbusers
ファイルの内容は以下の通り:
parsonsw: "William Parsons" marygee: geeringm
この例では、Windowsユーザーアカウント“William Parsons”はUNIXユーザー
parsonsw
にマップされ、Windowsユーザーアカウント
“geeringm”はUNIXユーザーmarygee
にマップされる。
3.0.11より前のすべてのSambaは、Sambaサーバー上で、ユーザー、グループ、共有、プリンター
とその他の管理を行うのに、root
アカウントしか使えなかった。
これは、何人かのユーザーには問題を引き起こし、しばしばUNIX/Linuxシステム上で、最も
セキュリティに敏感なアカウントの権限を渡す必要があるという弱点の元であった。
Sambaバージョン3.0.11から、ユーザーまたはユーザーが属するグループに対して必要に応じて
管理者権限を委譲する機能が加わった。管理者特権の重要性は“User Rights and Privileges”に
説明がある。ユーザー権限と権利管理に関するnet
コマンドの使用例は
この章の適切な箇所にある。
ユーザー権限と権利が正しく設定した場合、UNIX UID=0であるroot
ユーザー
(およびその同義語)のためのWindowsネットワークアカウントの必要がなくなる。初期のユーザー
権限と権利は、Domain Admins
グループのメンバーの任意のアカウントに
割り当てることが出来る。権利はグループアカウントと同じように割り当てられる。
既定値では、何らの権利と権限も割り当てられない。これは以下のコマンドを実行する ことで以下のように表示される:
root#
net rpc rights list accounts -U root%not24get
BUILTIN\Print Operators
No privileges assigned
BUILTIN\Account Operators
No privileges assigned
BUILTIN\Backup Operators
No privileges assigned
BUILTIN\Server Operators
No privileges assigned
BUILTIN\Administrators
No privileges assigned
Everyone
No privileges assigned
net
コマンドは、以下の方法で現在サポートされている権利と
権限を得るのに使える:
root#
net rpc rights list -U root%not24get
SeMachineAccountPrivilege Add machines to domain
SePrintOperatorPrivilege Manage printers
SeAddUsersPrivilege Add users and groups to the domain
SeRemoteShutdownPrivilege Force shutdown from a remote system
SeDiskOperatorPrivilege Manage disk shares
SeBackupPrivilege Back up files and directories
SeRestorePrivilege Restore files and directories
SeTakeOwnershipPrivilege Take ownership of files or other objects
Machine account権限は、Windows NT4以降のネットワーククライアントをドメインに 参加させるために必要である。disk operator権限は、ユーザーが所有していない オブジェクトの、共有のACLとファイルとディレクトリのACLを管理するために必要である。
この例では、すべての権利はDomain Admins
グループに割り当てられる。これは、このグループのメンバーが通常全権を有することになっている。この割り当ては以下のようになっている:
root#
net rpc rights grant "MIDEARTH\Domain Admins" \
SeMachineAccountPrivilege SePrintOperatorPrivilege \
SeAddUsersPrivilege SeRemoteShutdownPrivilege \
SeDiskOperatorPrivilege -U root%not24get
Successfully granted rights.
次に、ドメインユーザーjht
は、日々の管理の必要性のために権限を
割り当てられる:
root#
net rpc rights grant "MIDEARTH\jht" \
SeMachineAccountPrivilege SePrintOperatorPrivilege \
SeAddUsersPrivilege SeDiskOperatorPrivilege \
-U root%not24get
Successfully granted rights.
root#
net rpc rights list accounts -U root%not24get
MIDEARTH\jht
SeMachineAccountPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeDiskOperatorPrivilege
BUILTIN\Print Operators
No privileges assigned
BUILTIN\Account Operators
No privileges assigned
BUILTIN\Backup Operators
No privileges assigned
BUILTIN\Server Operators
No privileges assigned
BUILTIN\Administrators
No privileges assigned
Everyone
No privileges assigned
MIDEARTH\Domain Admins
SeMachineAccountPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeRemoteShutdownPrivilege
SeDiskOperatorPrivilege
基本的な信頼関係には2つのタイプがある:最初のものは、ドメインコントローラーと ドメインメンバーマシン(ネットワーククライアント)間のものであり、2番目のものは、 ドメイン間(ドメイン間信頼関係と呼ばれる)である。ドメインセキュリティに参加する すべてのSambaサーバーは、Windows NT/200x/XPワークステーションがそうであるように、 ドメインメンバーシップ信頼アカウントを必要とする。
それ自身の固有の設定を取得するために、netコマンドはsmb.conf
ファイルを見に行く。
そのため、以下のコマンドは、smb.conf
から、どのドメインに参加するかを知っている。
Sambaサーバーのドメイン信頼アカウントは以下の例のようにして確認できる:
root#
net rpc testjoin
Join to 'MIDEARTH' is OK
ここで、ドメインメンバーシップアカウントがないか、アカウントの認証が無効の場合、 以下の結果が表示される:
net rpc testjoin -S DOLPHIN Join to domain 'WORLDOCEAN' is not valid
The equivalent command for joining a Samba server to a Windows ADS domain is shown here:
root#
net ads testjoin
Using short domain name -- TAKEAWAY
Joined 'LEMONADE' to realm 'TAKEAWAY.BIZ'
ADSの信頼関係が確立されていない状態か、何らかの理由で無効になっている場合、 以下のエラーメッセージが表示される:
root#
net ads testjoin -UAdministrator%secret
Join to domain is not valid
以下は、コマンドが実行された時にSambaサーバーがターゲットのドメイン中でマシン 信頼アカウントを作成する手順を示す:
root#
net rpc join -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
SambaドメインにSambaサーバーを参加させると、マシンアカウントが作成される。 その例は以下の通り:
root#
pdbedit -Lw merlin\$
merlin$:1009:9B4489D6B90461FD6A3EC3AB96147E16:\
176D8C554E99914BDF3407DEA2231D80:[S ]:LCT-42891919:
大カッコの中のSは、これがサーバー(PDC/BDC)アカウントであることを意味する。 ドメインの参加は、純粋にワークステーションとして参加するために処理が行われ、 その場合はSはW(ワークステーションアカウントを意味する)に置き換えられる。 これを行うには以下のコマンドを使う:
root#
net rpc join member -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
コマンドラインパラメーターmember
はこれをjoin固有にすること
に注意。既定値では、タイプはsmb.conf
ファイルの設定から推測される。特に、PDC又は
BDCとしてjoinするためには、コマンドラインパラメーターを
[PDC | BDC]
とする。例をあげると、
root#
net rpc join bdc -S FRODO -Uroot%not24get
Joined domain MIDEARTH.
となる。これは、smb.conf
ファイル中の設定からドメインへのjoinのタイプを
Sambaに理解させるのに最も良い方法である。
Windows ADSにSambaサーバーをjoinさせるコマンドは以下の通り:
root#
net ads join -UAdministrator%not24get
Using short domain name -- GDANSK
Joined 'FRANDIMITZ' to realm 'GDANSK.ABMAS.BIZ'
NT4ドメインからマシンを削除するための特定のオプションはない。ドメインから削除
されるドメインメンバーがWindowsマシンの場合、ドメインメンバーシップアカウントは自動的
には削除されない。無効になっているドメインアカウントは、何らかのツールで削除する
ことが出来る。もしも必要ならば、マシンアカウントは以下のnet
コマンドで削除できる:
root#
net rpc user delete HERRING\$ -Uroot%not24get
Deleted user account.
削除は、マシンアカウントが末尾に$が付いたユーザーアカウントのようになっている ために可能となる。アカウント管理操作はユーザーとマシンアカウントの間で同じ方法で 扱える。
Windows ADS メンバーであるSamba-3サーバーはドメインから、以下のコマンドで離脱できる:
root#
net ads leave
ADSドメインについての詳細な情報は、以下を使ってSamba DMSマシンから得られる:
root#
net ads status
この件に関する情報は非常にたくさんある。詳細は“Samba-3 by Example” という書籍の第七章を参照してほしい。この本は書籍か、あるいはオンライン上では Samba-3 by Example (訳注:英語版)で入手できる。
ドメイン間の信頼関係は、あるドメインのユーザーが、他のドメインでアクセス許可と 権利を得ることが出来ることについての主要なメカニズムを構成する。
ドメイン間の信頼歓迎がどうなっているかを調べるには、以下のコマンドを実行する:
root#
net rpc trustdom list -Uroot%not24get
Trusted domains list:
none
Trusting domains list:
none
この時点ではドメイン間の信頼関係はない;以下のステップでこれを作成する。
ローカルドメインで信頼アカウントを作成することが必要である。2番目のドメイン中の ドメインコントローラーはこのアカウントを使って信頼された接続を作成できる。これは、 外部のドメインがローカルドメイン中でアクセスするために信頼されていると言うことを 意味する。このコマンドはローカル信頼アカウントを作成する:
root#
net rpc trustdom add DAMNATION f00db4r -Uroot%not24get
アカウントはpdbedit
を使って表示できる:
root#
pdbedit -Lw DAMNATION\$
DAMNATION$:1016:9AC1F121DF897688AAD3B435B51404EE: \
7F845808B91BB9F7FEF44B247D9DC9A6:[I ]:LCT-428934B1:
信頼アカウントはいつでも大括弧の中にIという値を持っている。
もしも信頼されているドメインへ接続できないと、以下のコマンドは失敗する:
root#
net rpc trustdom list -Uroot%not24get
Trusted domains list:
none
Trusting domains list:
DAMNATION S-1-5-21-1385457007-882775198-1210191635
The above command executed successfully; a failure is indicated when the following response is obtained:
net rpc trustdom list -Uroot%not24get Trusted domains list: DAMNATION S-1-5-21-1385457007-882775198-1210191635 Trusting domains list: DAMNATION domain controller is not responding
信頼アカウントが外部ドメインで作成された場合、Sambaは信頼関係を外部アカウントに 対して(接続して)確立する。プロセスの中で、リモートドメイン上でリソースに対する 1方向の信頼を確立する。このコマンドは信頼関係に参加する目的を達成する:
root#
net rpc trustdom establish DAMNATION
Password: xxxxxxx == f00db4r
Could not connect to server TRANSGRESSION
Trust to domain DAMNATION established
今確立した双方向の信頼関係の表示は以下のように行える:
root#
net rpc trustdom list -Uroot%not24get
Trusted domains list:
DAMNATION S-1-5-21-1385457007-882775198-1210191635
Trusting domains list:
DAMNATION S-1-5-21-1385457007-882775198-1210191635
時々、外部ドメインにアクセするためのローカルユーザーのための能力を取り去る必要が ある。信頼している接続は以下のように取り去ることが出来る:
root#
net rpc trustdom revoke DAMNATION -Uroot%not24get
また別の時には、ローカルドメイン内のリソースにアクセス出来る外部ドメインから、 ユーザーを削除する機能が必要な時がある。以下はこれを行えるようにする:
root#
net rpc trustdom del DAMNATION -Uroot%not24get
すべてのWindowsネットワーキング操作で使われる基本的なセキュリティ識別子は Windowsセキュリティ識別子(SID)である。すべてのWindowsネットワークマシン(サーバーと ワークステーション)、ユーザーとグループはそれぞれのSIDで確認される。すべてのデス クトッププロファイルも、ユーザーが存在しているドメインのSIDに固有のユーザーと グループSIDでエンコードされる。
保護のためにマシンやドメインのSIDをファイルに保存することは、本当に重要である。 なぜか?なぜならば、ホスト名中かドメイン(ワークグループ)中の名前の変更点が、 SID内の変更になるかもしれないからである。SIDが手元にある場合、それを回復さ せることは簡単な問題である。別の方法を取ると、ユーザーデスクトッププロファイルを 回復しなければならず、すべてのメンバーメンバーマシンを再結合しなければならないとい う手間暇で苦しむことになる。
最初に、ファイル中にローカルSIDを格納することを忘れないこと。smb.conf
が保存
されているディレクトリ中に配置しておくのは良い方法である。これを行うのは
以下のように行う:
root#
net getlocalsid > /etc/samba/my-sid
これで、ローカルのマシンSIDが安全に保存できた。PDC/BDC上ではドメインSID でもある。
以下のコマンドは、前者がmy-sid
と呼ばれているファイル中に
入れなければならなかったことを明らかにする:
root#
net getlocalsid
SID for domain MERLIN is: S-1-5-21-726309263-4128913605-1168186429
もしも、my-sid
ファイル中に格納されたSIDをリストアする
必要性がある場合、単純にSID(S-1-5-21
で始まる文字列)を
以下のコマンドラインのように行う:
root#
net setlocalsid S-1-5-21-1385457007-882775198-1210191635
マシンSIDのリストアは単純な操作であるが、バックアップコピーがないととて も大変である。
以下の操作はマシンがPDCまたはBDCに設定されている時のみ有用である。DMSとワーク ステーションクライアントは名前空間の競合の可能性を防ぐために固有のSIDを持つ べきである。以下は、BDCのSIDをPDCに同期する例である(これは既定値の NT4 ドメインの動作である):
root#
net rpc getsid -S FRODO -Uroot%not24get
Storing SID S-1-5-21-726309263-4128913605-1168186429 \
for Domain MIDEARTH in secrets.tdb
通常、ターゲットのサーバー(-S FRODO)や管理者アカウントのパスワード(-Uroot%not24get) を指定する必要はない。
共有管理は、すべてのファイルサービス操作にとって主要なものである。通常の共有 操作は以下を含む:
共有の作成/変更/削除
共有へのACLの設定/変更
サーバー間での共有の移動
共有内容のパーミッションの変更
上記のおのおのは、それらが必要としている範囲において、
net
コマンドを使ってここで分けられる。このコマンドの
範囲外の操作はこの文書のどこかで触れられている。
共有はnet rpc share
の能力を使って追加できる。ターゲットマシン
はローカルまたは-Sオプションを指定することでリモートでもよい。このツールを使った
共有の追加と削除は、適切なインタフェーススクリプトが有効であることに依存する
ことに注意しなければならない。Sambaのsmbd
が使うインタフェース
スクリプトは、add share command、
delete share commandと
smbconfoption name="change share command"/>と呼ばれる。スクリプトの例一式は、
Sambaのソース内のディレクトリ~samba/examples/scripts
で提供されている。
以下のステップは、net
ユーティリティの共有管理能力を使う例を
表示する。最初のステップで、Bulge
という共有が追加される。
ファイルシステム内の共有ポイントは/data
というディレクトリ
である。この共有を追加するためのコマンドの実行例は以下の通り:
root#
net rpc share add Bulge=/data -S MERLIN -Uroot%not24get
検証は重要なプロセスで、何もオプションを付けないでnet rpc share
を実行することで、以下のように有効な共有のリストを得ることが出来る:
root#
net rpc share -S MERLIN -Uroot%not24get
profdata
archive
Bulge <--- This one was added
print$
netlogon
profiles
IPC$
kyocera
ADMIN$
コマンドラインツールを使って共有を削除することもしばしば好ましい。以下の手順では、 以前に作成した共有を削除する:
root#
net rpc share delete Bulge -S MERLIN -Uroot%not24get
共有が削除された結果の簡単な検証は以下の通り:
root#
net rpc share -S MERLIN -Uroot%not24get
profdata
archive
print$
netlogon
profiles
IPC$
ADMIN$
kyocera
現時点で、net
ツールはSamba共有上のACLを管理するのには使えない。
Microsoft Windowsの用語で、これは、共有のアクセス許可(訳注:Share Permissions)
と呼ばれる。
SRVTOOLの NT4ドメインサーバーマネージャかコンピュータの管理のMMCスナップインの どちらかを使うことでSamba共有上のACLを設定することが可能である。それらは ここでは触れないので、“ファイル、ディレクトリと共有のアクセス制御”を参照のこと。
共有とファイルはユーザー、マシンとグループアカウントと同じように移行できる。移行
プロセスを通じて、セキュリティの設定と同様にアクセス制御(ACL)の設定を保持する
ことは可能である。net rpc vampire
昨日は、Windows NT4(か
それ以降)からSambaサーバーにアカウントを移行する時に使われる。このプロセスは
パスワードとアカウントセキュリティの設定を保持し、共有とファイルの移行のための
前身である。
net rpc share
コマンドは共有、ディレクトリ、ファイルとその他の
該当するデータをWindowsサーバーからSambaサーバーに移行するのに使うことが出来る。
コマンドラインスイッチは、Windowsファイルサーバーのほとんど直接のクローンを作成できる。 たとえば、ファイルサーバーを移行するとき、WindowsサーバーのファイルのACLとDOSファイル 属性は以降プロセスの中に含まれ、移行が完了したときにSambaサーバー上で、ほとんど同じ ように現れる。
以降プロセスはSambaサーバーが完全に動作可能な時にのみ完了できる。ユーザーとグループ アカウントは、データの共有、ファイルとプリンターを移行する前に移行されねばならない。 ファイルとプリンター設定の移行は、SMBとMS DCE RPCサービスの両方を使用する。移行の プロセスでの良い方法は、あるサーバーから他へのデータの転送に影響する"中間者" (訳注:man-in-middle)による移行としてSambaサーバーを使うために現在存在するように 実装されている。たとえば、もしもSambaサーバーがMESSERという名前で、移行元の Windows NTサーバーがPEPPYという名前で、移行先のSambaサーバーがGONZALESであれば、 マシンMESSERはすべてのデータ(ファイルと共有)をPEPPYからGONZALESに移行を行う のに使うことが出来る。もしも移行先が指定されていない場合、ローカルサーバーが 既定値として、ネットワーク上での一般的な原則のように仮定される。
サーバー移行を成功裏に行うには、移行作業がとても依存するプロセスのように移行元の サーバー(かドメイン)の構造をしっかり理解しておくことが要求される。
移行プロセスでは2つの制限が知られている:
net
コマンドは移行元と移行先両方でユーザー資格証明が
存在することを必要とする。
プリンターの設定は完全に移行できないか不正になるかもしれない。これは、 Windows 2003 サーバーをSambaに移行する際に特に発生するかもしれない。
net rpc share migrate
コマンド操作は簡単な共有セクションの移行
ができる。セクションはファイル又はプリンター共有が定義されているパラメーターを含む。
この移行方法はパラメーターとして、ファイルシステムディレクトリパス、オプション記述
と、ファイルへの書き込み許可を行う単純なセキュリティ設定を持つ共有セクションを
作成する。以下の移行で必要な最初のステップの1つは、共有セクションの設定が利用に
適しているかを確認することである。
共有は移行プロセスの一部として動的に作成される。smbd
は、
smb.conf
パラメーターのadd share command
によって
指定されるスクリプトを実行するためにOSを呼び出すことでこのことを行う。
$SAMBA_SOURCES/examples/scripts
ディレクトリ中に
add share command
のための適切な例がある。移行を
行うときに使うアカウントは、必要に応じて、適切なファイルシステムへのアクセス
権とそれらに対するACL設定および共有の作成権限を持たねばならないことに注意。
そのような権限は、SeAddUsersPrivilege
と
SeDiskOperatorPrivilege
という権限である。
権限と権利についてのより詳細な情報は、“User Rights and Privileges”を参照のこと。
共有の移行のためのコマンドの文法は以下の通り:
net rpc share MIGRATE SHARES <share-name> -S <source> [--destination=localhost] [--exclude=share1,share2] [-v]
When the parameter <share-name> is omitted, all shares will be migrated. The potentially
large list of available shares on the system that is being migrated can be limited using the
--exclude
switch. For example:
root#
net rpc share migrate shares myshare\
-S win2k -U administrator%secret"
これは、パスワードがsecret
であるアカウント
administrator
に結びついたパーミッションを使ったSambaサーバーに
win2k
というサーバーから共有myshare
を
移行する。使用するアカウントは移行元と移行先のSambaサーバーで同じでなければ
ならない。共有の移行に先だってnet rpc vampire
を使用する
には、両方のシステムでアカウントが同じにしておく必要がある。共有の移行開始の
前に行う価値があることは、移行するアカウント(Sambaサーバー上)が必要とする権利と
権限について確認しておくことである。これは以下のように行う:
root#
net rpc right list accounts -Uroot%not24get
ここまでの手順で実行されることは、共有の移行だけである。ディレクトリと ディレクトリ中に含まれるものは、この時点で、今までの手順では移行されない。
この時点でカバーされてきたすべてのことは、ファイルとディレクトリデータの移行の
準備である。多くの人にとって、準備作業は退屈であり、ファイルとデータを使える
時になってやっと感激が得られる。次の手順は、net
コマンドを
使ってデータファイルを転送(移行)するのに使えるテクニックを示す:
1つのサーバーから他にファイルを転送することは、Windows NTと200xサーバーが、いつでも
必要とされるツールを含んでいないために、Microsoft Windows管理者にとって挑戦的な
作業である。Windows NTからのxcopy
コマンドはファイルと
ディレクトリのACLを保存する能力がなく、Windows 200xのみができる。Microsoftは
scopy
と呼ばれる、ACL(セキュリティの設定)をコピーできる
ユーティリティを提供していないが、それは、Windows NT か 200xのサーバーリソース
キットの一部として提供している。
商用またはフリーウェアでWindowsサーバーから、完全なセキュリティ設定の維持をしながら
ファイルとディレクトリのコピーを行うのに使えるツールがある。よく知られている
フリーなツールで一番よいものは、robocopy
というものである。
net
ユーティリティは、DOSファイル属性と同じように、完全にACLを
保持しながらファイルとディレクトリのコピーを行うのに使える。注意すべきは、
ACLを含むことは、移行先のシステムが、移行元のシステムと同じセキュリティ
コンテキストの範囲内で 操作できるときにのみ意味をなすと言うことである。これは、
vawpireコマンドを使われたドメインからの結果のDMSとドメインコントローラーの両方に
適用される。ファイルとディレクトリの移行の前にすべての共有はすでに存在しなければ
ならない。
移行コマンドの文法は以下の通りである:
net rpc share MIGRATE FILES <share-name> -S <source> [--destination=localhost] [--exclude=share1,share2] [--acls] [--attrs] [--timestamps] [-v]
もしも、<share-name>パラメーターが省略された場合、すべての共有が移行される。
移行元システム上での、潜在的にある大量の共有の一覧は、
--exclude
コマンドスイッチで制限できる。
すべてのファイルのACLを保存することが必要な場合、--acls
スイッチは上記のコマンドラインに追加すべきである。オリジナルのファイルの
タイムスタンプは--timestamps
スイッチを指定することで
保存でき、DOSファイル属性(すなわち hidden,archiveなど)は
--attrs
スイッチを指定することで保存できる。
ACLの保存の能力は、移行先のサーバー上のホストOSの一般的なファイルシステムの機能と 同じように適切なACLのサポートに依存する。Windowsファイルサーバーから他への 移行は、すべてのファイル属性を完全に保存する。WindowsのACLをPOSIX ACLをサポート しているシステム上へのマッピングが困難なため、Windows ACLをSambaサーバーへ 完全に移行することはできない。
Sambaサーバー上でのACLの結果はオリジナルのACLには、おおかた一致しない。Windowsは
グループのみで所有されるファイルをサポートしている。グループのみが所有する
ファイルはUNIX/Linuxでは不可能である。移行におけるエラーは、smb.conf
ファイル
中にforce unknown acl user = yes
パラメーターを使うことで防ぐことが出来る。この機能は自動的に、グループのみが所有
するファイルを、Windows上でユーザーが所有するファイルに修正する。
nt4box
というマシンから、Sambaサーバーへのファイルの移行の
手続きの例は以下の通り:
root#
net rpc share migrate files -S nt4box --acls \
--attrs -U administrator%secret
このコマンドは、nt4box
というWindowsサーバーから、移行作業を
始めるSambaサーバーに、すべての共有の、すべてのファイルとディレクトリを移行する。
グループのみが所有するファイルは administrator
という
ユーザーアカウントが所有するようになる。
Administratorであっても、その中に任意のファイルやディレクトリをコピー できない、共有のアクセス許可(セキュリティ記述子)を設定することは可能である。 そのため、共有のアクセス許可は、独立した機能で用意されている:
root#
net rpc share migrate security -S nt4box -U administrator%secret
このコマンドは、ローカルのSambaシステムへ、nt4box上の各共有のにおける、共有の アクセス許可のみをコピーする。
以下で示される動作モードは今まで示したものを組み合わせたものである。これは 最初に共有の定義を移行し、次にすべての共有されているファイルとディレクトリを、 最後に共有のアクセス許可を移行する:
net rpc share MIGRATE ALL <share-name> -S <source> [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]
root#
net rpc share migrate all -S w2k3server -U administrator%secret
これは、w2k3server
サーバーの完全な複製を生成する。
新しいネットワーク環境への移行と同様、新しいサーバーをインストールすることは、 しばしば家を建てることと類似している。基礎を作るところから家の構造部分の 完成までのステージは進歩がとても早いが、建築作業が完成に近づくにつれ、 仕上げ作業はより長くかかるように見える。
印刷の必要性は、ネットワーク環境にとても大きく依存し、とても簡単かもしれないが、 複雑かもしれない。もし必要性がとても単純ならば、印刷サポートを実装する最も良い 解決法は、古い設定から移行する代わりに、白紙の状態からすべてを再インストール することである。別の言い方をすると、たくさんの国際オフィスとたくさんある ローカルな支店が、印刷機能の拠点間で複雑怪奇になっているように統合された複雑な ネットワークのプリンター設定を移行することは、とてつもなく有望である。手動で 複雑な印刷ネットワークを再インストールするのは、とても時間がかかり、 フラストレーションが溜まる。しばしば、今使っているドライバーファイルを見つける のが困難で、より新しいバージョンのドライバーのインストールが必要となる。新しい ドライバーはしばしばプリンターの使用方法の変更を必要とする印刷機能を実装している。 更に追加で、非常に複雑な印刷設定は、それがどんなに広範囲に文書化されたとしても、 同じ環境を再作成することはほとんど不可能になる。、
既存の印刷構成の移行は以下のように行う:
印刷キューを確立する。
プリンタードライバーをインストールする(プリントサーバーとWindowsクライアント上両方)。
印刷フォームを設定する。
セキュリティの設定を行う。
プリンターの設定を行う。
Sambaのnet
ユーティリティは1つのWindowsプリントサーバーから
他への移行ができる。このツールをSambaサーバーsmbd
に対して
プリンターを移行するのに使った時、必要なサービスを作成するためにネットワーク
リクエストを受け取るアプリケーションは、配下のプリンターを作成するためにOS
を呼び出さなければならない。OS呼び出しは、smb.conf
ファイル中のパラメーター
で指定することが出来るインタフェース
パラメーターを経由して行われる。このスクリプトは移行プロセスで必須である。
適切なスクリプトの例は、
$SAMBA_SOURCES/examples/scripts
から得られる。
このスクリプトはOS環境に適するようにカスタマイズせねばならず、また、プリント
キューを作成するためにこのツールを使うことも出来る。
上記で説明した各コンポーネントは、個別に完了することが出来、また、自動操作の 一部として完了することができる。多くのネットワーク管理者は、特に事がうまく 行かない時、移行の問題を最も手慣れた手法で対処することを好む。各操作の 文法を簡単に以下で説明する。
Windows サーバー(NT4または200x)からのプリンター移行は以下である。この手順は、 プリンター共有を、ベースとなるプリントキューとともに作成する:
net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
プリンタードライバーをWindowsプリントサーバーからSambaサーバーに移行するのには、この コマンドライン操作を使用する:
net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
プリンターのセキュリティ設定(ACL)は以下のコマンドを使うことでWindowsサーバーからSambaサーバーに移行できる:
net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
プリンター構成の設定は、紙のサイズや既定値の紙の方向のような要素を含む。 これらは以下のコマンドを使うことでWindowsサーバーからSambaサーバーに移行できる:
net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
上記で説明した情報を含むプリンターの移行は、以下の文法を使う単一のコマンドで完了しても良い:
net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
マニュアルページには、RAPかRPC機能呼び出しのどちらかを使うオープンしている
ファイルをクローズするためのツールを提供する、net file
コマンドの機能について説明がある。特定なし用法の情報についてのマニュアル
ページを参照してほしい。
net session
コマンドのセッション管理インタフェースは、以下の
ようにSambaサーバーへの接続の一覧を示すための古いRAPメソッドを使う:
root#
net rap session -S MERLIN -Uroot%not24get
Computer User name Client Type Opens Idle time
------------------------------------------------------------------------------
\\merlin root Unknown Client 0 00:00:00
\\marvel jht Unknown Client 0 00:00:00
\\maggot jht Unknown Client 0 00:00:00
\\marvel jht Unknown Client 0 00:00:00
セッションは以下のコマンドを実行することでクローズできる:
root#
net rap session close marvel -Uroot%not24get
Samba-3がMicrosoft Windows ADS環境で使われる場合、Samba経由で共有されるプリンターは
ADSドメインに対して公開されるまではブラウズできない。公開されたプリンターに関する
情報は以下の文法で、net ads print info
コマンドを実行する
ことで、ADSから入手できる:
net ads printer info <printer_name> <server_name> -Uadministrator%secret
もしも星印(*)がプリンター名引数の場所で使われた場合、すべてのプリンターの一覧が返る。
ADSに対してプリンターを公開する(有効にする)には、以下のコマンドを実行する:
net ads printer publish <printer_name> -Uadministrator%secret
これはローカルSambaサーバーのプリンターをADSに公開する。
ADSからSambaプリンターを削除するには、以下のコマンドを実行する:
net ads printer remove <printer_name> -Uadministrator%secret
ADSドメイン全体に渡ってプリンターの場所を調べる一般的な検索(問い合わせ)も、以下を使うことで出来る:
net ads printer search <printer_name> -Uadministrator%secret
winbindd
によって、IDMAP UIDからSIDとSIDからUIDへのマッピング
は、テキストファイルにバックアップできる。テキストファイルは、手動で編集
できるが、自分自身が正確に何をやっているのかを知っている時にのみ、それを行う
ことを強く推奨する。
IDMAP テキストダンプファイルはリストア(再ロード)できる。この動作が必要とされる 2つの状況は次の通り: a) 存在するIDMAPファイルが壊れたか、b)編集されたマッピング 情報をインストールする必要がある場合。
WinbindはIDMAPファイルをダンプするためには停止しなければならない。ダンプファイルを
リストアする前に、winbindd
を停止し、古い
winbindd_idmap.tdb
ファイルを削除する。
IDMAPデータベースは以下の方法でテキストファイルにダンプできる:
net idmap dump <full_path_and_tdb_filename> > dumpfile.txt
ここで、特定のSambaのビルドのランタイムtdbファイルが、ダンプファイルを
作成するための以下のコマンドで、/var/lib/samba
ディレクトリに格納される:
net idmap dump /var/lib/samba/winbindd_idmap.tdb > idmap_dump.txt
以下のコマンドは、Sambaドメインに関して基本的な統計を取るのに便利である。 このコマンドは現在のWindows XP Professionalクライアントでは動作しない。
root#
net rpc info
Domain Name: RAPIDFLY
Domain SID: S-1-5-21-399034208-633907489-3292421255
Sequence number: 1116312355
Num users: 720
Num domain groups: 27
Num local groups: 6
そのほかの便利なツールは、net time
サブコマンド群である。この
サブコマンド群は以下のように、対象のサーバー上の現在の時刻を問い合わせるのに使える:
root#
net time -S SAURON
Tue May 17 00:50:43 2005
UNIXの/bin/time
から得られる時刻情報を渡すことが目的の場合は、
渡すために準備されたフォーマットで対象のサーバーから時刻を得るのはよい方法である。
これは、以下を実行することで行える:
root#
net time system -S FRODO
051700532005.16
root#
net time set -S MAGGOT -U Administrator%not24get
Tue May 17 00:55:30 MDT 2005
以下のコマンドを実行することで、サーバーのタイムゾーンを得ることが出来る:
root#
net time zone -S SAURON
-0600
Table of Contents
Microsoft Windows オペレーティングシステムは、Sambaを実装したOSとの間での相互運用性を 行うために、難しい問題を要求してくるといういくつかの特徴がある。この章では、 SambaサーバーをMicrosoft Windowsネットワーク環境に統合するための難問の1つを解決するために 使う、Samba-3(バージョン 3.0.8以降)のメカニズムについて明示的に説明する。この章では、 Windowsのセキュリティ識別子(SID)をUNIXのUIDとGIDについての識別情報マッピング(IDMAP) について説明する。
いろいろな場面において十分に適用出来るようにするため、各可能なSambaの配布タイプに ついて解説を行う。これは、どのようにIDMAP機能が実装されたかについての概要によって フォローされる。
IDMAP機能は、複数のSambaサーバー(またはSambaネットワーククライアント)がドメイン中で インストールされている場合に重要である。単一のSambaサーバーにおいては、IDMAP基盤 については余り気にかける必要はない。既定値におけるSambaの動作はほとんど の場合、十分に使えるものである。複数のSambaサーバーが使われる場合、あるサーバーから 別のサーバーにデータを移動する時にはしばしばこれが必要で、それはやっかい事が始まる 所でもある!
LDAPディレクトリ中にユーザーとグループアカウント情報が格納されている場合、すべてのサーバーは
ユーザーとグループに対して一貫したUIDとGIDを使うことが出来る。これは、NSSとnss_ldapツール
を使うことで出来る。Sambaはローカルアカウントのみを使うように設定出来、その場合、IDMAP
での問題が発生する範囲は若干少なくなる。これは、サーバーが単一のドメインに属していて、
ドメイン間の信頼関係が必要ない時に有効に動作する。別の言い方をすると、もしもSamba
サーバーがNT4ドメインのメンバーかADSのドメインメンバーである場合か、不慮のクロスオーバーが
ないように、セキュリティ名前空間を保持する必要がある場合、(すなわち、ユーザー
DOMINICUS\FJones
はFRANCISCUS\FJones
という
ユーザーのアカウントリソースへのアクセスが出来ないようにしなければならない)
[4]クローズする試みは、
IDMAP機能が設定されているという方法に対して提供されなければならない。
IDMAPの使用は、Sambaサーバーが一つ以上のドメインからワークステーションまたはサーバーによって アクセスされる場合に重要であり、そのような場合、winbindを動作させることが重要で、そうする と、外部のSIDをローカルのUNIX UIDとGIDに解決(IDマッピング)することが出来るようになる。
IDMAP機能は、Samba起動時にwinbindd
の実行を必要とする。
4つの基本的なサーバータイプがあり、これは、 サーバータイプとセキュリティモードの章に 説明がある。
スタンドアロンSambaサーバーはWindows NT4ドメイン、Windows 200x Active Directory ドメインかSambaドメインのメンバーでない形で動く。
定義により、これは、ユーザーとグループはローカルに作成/制御され、ネットワーク ユーザーの識別はローカルのUNIX/Linuxユーザーログイン情報に一致しなければならない。 そのため、IDMAP機能はほとんど関心を払う必要はなく、winbindも不要で、IDMAP 機能は関連しないか、興味を持つべきものではない。
Samba-3はWindows NT4 PDCまたはBDCとして動作でき、それによって、Windows NT4と 互換性を持つドメイン制御プロトコルを提供する。Samba-3のファイルと印刷共有 プロトコルはすべてのバージョンのMicrosoft Windows製品と互換がある。Windows NT4は Microsoft Windows Active Directoryと同様、広範囲にWindows SIDを使用する。
Samba-3ドメインメンバーサーバーとクライアントはMicrosoft Windows SIDと正しく相互に 処理を行わなければならない。入力されたSIDはローカルのUNIX UIDとGIDに変換され なければならない。Sambaサーバーから出力する情報は、適切なSIDでMicrosoft Windows クライアントとサーバーに提供されなければならない。
Windowsネットワークドメイン(NT4形式またはADS)のメンバーであるSambaはいろいろな
方法で識別情報のマッピングを扱うように設定出来る。使用するメカニズムは、
winbindd
デーモンが使われるか否かとどのようにwinbindの
機能が設定されているかに依存する。設定オプションの簡単な説明は以下の通り:
winbindd
が使われないと、Samba
(smbd
)は、入力されたネットワークからの
情報の識別を解決するための、基本的なUNIX/Linuxメカニズムを
使用する。これは、セッションセットアップ要求時にLoginID
(アカウント名)を使い、getpwnam()システムファンクションコール
にそれを渡す。この呼び出しは最近のUNIX/Linuxシステム上では
ネームサービススイッチ(NSS)メカニズムを使うように実装されて
いる。"ユーザーとグループがローカル"という場合、それらは
ローカルシステム上の、/etc/passwd
と
/etc/group
にそれぞれ格納されることを
意味する。
たとえば、ユーザーBERYLIUM\WambatW
が
Sambaサーバーに対して接続をオープンしようとする場合、
入力されるSessionSetupAndX要求は、/etc/passwd
ファイル中のユーザーWambatW
を検索するために
システムを呼び出す。
この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。
この場合、ユーザーとグループアカウントは、ローカルアカウントとして 取り扱われる。ローカルアカウントそのものとただ1つ違う点は、 共有可能なリポジトリ内にアカウントが格納されると言うことである。 一般的には、これは、NIS形式のデータベースか、そうでなければ LDAP内にあると言うことである。
この設定は、スタンドアロンSambaサーバー、ドメインメンバーサーバー (NT4またはADS)とsmbpasswdまたはtdbsamベースのSamba passdb バックエンドを使うPDCに対して使うことが出来る。
Windows NT4ドメインかADSドメインのメンバーである単一のSamba サーバーか単純なSambaサーバーのみを必要とするサイトは多数ある。 標準的なサーバーの例は、ドメイン用のドメインコントローラー からアカウント認証情報を入手するためにwinbindを使うように 設定され、ローカルアカウントを持たないアプライアンスの ようなファイルサーバーである。ドメイン制御機能は、Samba-3、 Microsoft Windows NT4かMicrosoft Windows Active Directory によって提供される。
Winbindは、この状態においては非常に有益である。必要と
されるすべては、smb.conf
ファイル中で定義することが出来る
UIDとGIDの値の範囲である。/etc/nsswitch.conf
ファイルは、入力されたSIDを適切なUIDとGIDにマッピングする
ための、すべての難しい作業をこなすwinbind
を使うために設定される。SIDはwinbindがそれを受け取る順で
UID/GIDに割り当てられる。
この設定は、複数のSambaサーバーにまたがってUID/GIDとユーザーや グループとのマッピングが同一であることが求められる環境(サイト) では実用的でない。この方法の危険性の1つは、winbind機構の IDMAPデータベースファイルが壊れるか喪失した場合、IDMAP ファイル修正、再生成しても、UIDやGIDが以前と異なるユーザーや グループにマッピングされてしまい、結果としてSambaサーバー上に 格納されたWindowsファイルの所有者が不正になってしまう可能性 がある点である。
IDMAP_RID機能はSamba 3.0.8から提供された。これは、 ADSスキーマ拡張を適用しないMicrosoft ADSを使用する ことに関わりがあり、IDMAPテーブルをメンテナンスする 目的のためにLDAPディレクトリサーバーをインストールして いない、たくさんのサイトのために作業を簡単にする。 もしも単一のADSドメイン(ドメインのフォレストではなく 複数のドメインツリーでない)で、IDMAPテーブル問題に 対して単純なステレオタイプの解決方法を望んでいるなら、 IDMAP_RIDは明らかな選択肢である。
この機能はidmap uid
と
idmap gid
のレンジを割り当てることを
要求し、それが、SIDの相対識別子(RID)の部分を直接UIDのベースにRIDの
値を足した分に、自動マッピングするための、このレンジの
サブセットを割り当てることが可能な
idmap uid
の範囲内であることを要求する。
たとえば、もしもidmap uid
の範囲が
1000-100000000
で、
idmap backend = idmap_rid:DOMAIN_NAME=1000-50000000
で、発生したSIDが
S-1-5-21-34567898-12529001-32973135-1234
という値ならば、結果のUIDは1000 + 1234 = 2234
である。
この設定では、winbind
はsmb.conf
ファイル内で
指定されたidmap uid
と
idmap gid
の範囲からSIDからUIDとGIDに
解決を行うが、ローカルのwinbind IDMAPテーブルを使う代わりに、
すべてのドメインメンバーマシン(クライアントとサーバー)が共通の
IDMAPテーブルを共有できるためのLDAPディレクトリ中に格納された
ものを使う。
すべてのLDAP IDMAPクライアントは、smb.conf
ファイル中の
idmap backend
機能がLDAPリダイレクトを
正しく扱えないため、マスターLDAPサーバーのみを使うということは
重要である。
passdb バックエンドとしてのLDAPの使用はPDC、BDCとドメイン メンバーサーバーに対する優れた解である。それは、UID、GIDと 一致したSIDがすべてのサーバー間で首尾一貫している事を 保証するきちんとした解である。
LDAPベースのpassdbバックエンドの使用は、PADL nss_ldap ユーティリティか同等品を要求する。この状況の場合、 winbindは外部のSID、すなわち、スタンドアロン WindowsクライアントからのSID(すなわち、このドメインの メンバーでない)を他のドメインからのSIDと同じように 扱うために使われる。外部のUID/GIDは、ローカルのIDMAP テーブルでwinbindを使う時と同じ方法で正確に、 割り当てられた範囲(idmap uidとidmap gid)にマップされる。
nss_ldapツールセットはActive Directory経由と同様に、LDAP 経由でUIDとGIDにアクセスするために使われる。Active Directory を使うために、AD4UNIXスキーマ拡張か、Microsoft Services for UNIXバージョン3.5かそれ以降のどちらかをを、UNIXアカウント 認証情報を管理するために、ADSスキーマを 拡張するために インストールしてADSスキーマを変更することが必要である。 ADSスキーマが拡張されると、Microsoft管理コンソール(MMC) スナップインもADSのユーザーとコンピュータ管理ツールから UNIXの認証情報を設定/管理することが出来るようにインストール される。各アカウントは、UIDとGIDデータがSambaによって使われる ことが出来る前に、UNIXで有効な状態と分離されなければならない。
Microsoft Windowsドメインセキュリティシステムは、アカウント作成のプロセスの
一部として、ユーザーとグループSIDを生成する。WindowsはUNIXのUIDかGIDのような
概念を持たない。その代わり、固有のタイプのセキュリティ記述子を持つ。Sambaが
ドメインコントローラーとして使われる時、各ユーザーとグループに固有のSIDを生成する
手段を提供する。Sambaは、smb.conf
ファイル中で指定されたベースの値にUID
またはGIDを2倍した値を足すという算術的に計算されたRIDを足すマシンとドメイン
SIDを生成する。この方法は“算術的マッピング”と呼ばれる。
例をあげると、もしもユーザーのUIDが4321の場合、算術的なRIDベースが1000だとすると、
RIDは1000 + (2 x 4321) = 9642
となる。そのため、もしもドメイン
SIDがS-1-5-21-89238497-92787123-12341112
ならば、
結果のSIDはS-1-5-21-89238497-92787123-12341112-9642
となる。
前述のタイプのSIDはSambaによって、自動的な機能としてその場で生成されるか
(passdb backend = [tdbsam | smbpasswd]
を使った場合)、
あるいはLDAPベースのldapsam中でアカウントの一部として恒久的に格納されても
よい。
ADSはUIDとGIDのような追加のアカウント属性に適応するために拡張できるディレクトリ スキーマを使う。Microsoft Service for UNIX 3.5をインストールすると、通常のADS スキーマをUNIXアカウント属性を含むように拡張する。これらはもちろん通常の ADSアカウント管理のMMCインタフェーススナップインモジュールを等して別途管理され なければならない。
ドメイン内で使われるセキュリティ識別子は、競合を避けるためと完全性を保つために 管理されねばならない。NT4ドメインコンテキスト中で、PDCはすべてのセキュリティ 認証情報の、バックアップドメインコントローラー(BDC)への配布を管理する。現時点で、 そのような情報のために適したSambaドメインコントローラーのpassdbバックエンドは、 LDAP中バックエンドのみである。
winbind
を使う誰にとっても、下記の設定例は有用である。多くの場合、
winbind
は、ドメインメンバーサーバー(DMS)とドメインメンバークライアント
(DMC)を使うために一番興味がある事項である。
2つの共通的な設定が使われる:
ネットワーク上にNT4 PDC(BDCがあってもなくても)かSambaPDC(BDCがあってもなくても)がある。
ネットワークは Microsoft Windows 200x ADSを使っている。
NT4ドメインメンバーサーバーのsmb.conは、NT4
DMSに対するsmb.conf
ファイルのグローバルセクション部分の例を示す。
winbind
の使用は、NSSの設定を必要とする。以下を含むように
/etc/nsswitch.conf
のエントリを編集する:
... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files [dns] wins ...
ホストエントリでDNSを使う場合は、サイト上でDNSが使われている場合にのみ行う。
DMSを作成するには以下のような手順を踏む:
上記の設定を使って、smb.conf
ファイルを作成するかインストールする。
以下を実行する:
root#
net rpc join -UAdministrator%password
Joined domain MEGANET2.
ドメインへの参加が成功するかどうかは、以下のコマンドで確認できる:
root#
net rpc testjoin
Join to 'MIDEARTH' is OK
ドメインへの参加が失敗した場合、以下のようなエラーメッセージが出力される:
root#
net rpc testjoin
[2004/11/05 16:34:12, 0] utils/net_rpc_join.c:net_rpc_join_ok(66)
Join to domain 'MEGANET2' is not valid
ADSドメインへの参加手続きは、NT4ドメインへの参加と似ているが、smb.conf
ファイルは
ADSドメインメンバーサーバーのsmb.confで示された
内容の部分が異なる。
ADSのDMS操作はkerberos(KRB)を使用すること要求する。これを動作させるため、
krb5.conf
ファイルを設定する必要がある。正確な要求
内容は、どのバージョンのMITかHeimdal kerberosが使われているかに依存する。
現時点でMIT Kerberosのバージョンが1.3.5で、Heimdal が 0.61である最新の
バージョンのみを使うことを推奨する。
DMSを作成するには以下のステップを必要とする:
上記の設定でsmb.conf
ファイルを作成するかインストールする。
上記で示されたように、/etc/nsswitch.conf
ファイルを編集する。
root#
net ads join -UAdministrator%password
Joined domain BUTTERNET.
ドメインへの参加が成功するか失敗するかは以下のコマンドで確認出来る:
root#
net ads testjoin
Using short domain name -- BUTTERNET
Joined 'GARGOYLE' to realm 'BUTTERNET.BIZ'
ドメインへの参加が不正か失敗するかは以下を実行することで検出できる:
root#
net ads testjoin
GARGOYLE$@'s password:
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
ads_connect: No results returned
Join to domain is not valid
特定のエラーメッセージは、発生した不成功のタイプに依存するため、
上記とは異なるかもしれない。log level
を10まで
増やし、テストを再実行し、失敗の真の原因を探るために、生成されたログ
ファイルを調べること。
nmbd
, winbind
と smbd
デーモンをこの順番で起動する。
idmap_rid
機能は、ネイティブなwinbindとは異なり、新しい
ツールで、MicrosoftのSIDをUNIXのUIDとGIDに、予測可能なマッピングを作成する。
Samba IDMAP機能にこの手法を実装する一番の利点は、集中したIDMAPデータを保存する
必要性をなくすということである。不都合な点は、単一のADSドメイン内のみで使う
事ができる事と、ドメイン間信頼機能とは互換性がないことである。
このSIDからUID/GIDへのマッピングにおける代替手法はidmap_ridプラグインを
使って実現できる。このプラグインは、RIDに指定されたベース値を加える事に
よってUIDとGIDを引き出すために、ユーザーSIDのRIDを使う。このユーティリティは
複数のドメイン環境とは互換がない、“allow trusted domains = No”
パラメーターを指定することを要求する。idmap uid
と
idmap gid
の範囲を指定する必要がある。
idmap_rid機能はNT4/Samba形式のドメインとActive Directoryで使える。これをNT4
ドメインで使うためには、realm
パラメーターを含んでは
いけない。さらに、ドメインに参加するために使う手法は、
net rpc join
を使う。
ADSドメイン環境でのsmb.conf
ファイルの例は、
idmap_ridを使うADSドメインメンバーのsmb.conf
である。
Example 14.3. idmap_ridを使うADSドメインメンバーのsmb.conf
たくさんのユーザーが居る大きなドメイン中で、ユーザーとグループを列挙することを無効に
することは避けられない。例えば、Active Directory中に22000人ものユーザーが居る
サイトで、winbindベースのユーザーとグループの解決は、winbind
を
最初に開始する時点から12分以上利用できない。列挙を無効にすると、瞬間的に反応が
返る。ユーザーとグループの列挙を無効にすると言うことは、getent passwd
とgetent group
コマンドを使ってユーザーかグループの一覧を
表示することが出来ないと言うことである。特定のユーザーのみを検索することは
以下のような方法で可能である。
このツールを使用するには、ネイティブなwinbindの使用ごとにNSSの設定を必要とする。
以下のパラメーターを含むように/etc/nsswitch.conf
ファイルを
編集する。
... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files wins ...
以下の手順でidmap_rid機能を使うことが出来る:
上記の設定でsmb.conf
ファイルを作成またはインストールする。
上記で示されたように/etc/nsswitch.conf
ファイルを編集する。
以下を実行する:
root#
net ads join -UAdministrator%password
Using short domain name -- KPAK
Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
ドメインへの参加が不正または失敗するかは以下を実行することで検出できる:
root#
net ads testjoin
BIGJOE$@'s password:
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
ads_connect: No results returned
Join to domain is not valid
特定のエラーメッセージは、発生した問題のタイプに依存するため、上記と
異なるかもしれない。log level
を10まであげて、
テストを再実行し、失敗の真の原因を識別するために生成したログファイルを
調べること。
nmbd
, winbind
とsmbd
デーモンをこの順番で起動する。
root#
getent passwd administrator
administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
IDMAPの情報をLDAP中に格納することは、NT4/Samba-3形式のドメインとADSドメインで 利用できる。OpenLDAPは、多くの標準準拠のLDAPサーバーが使われているにもかかわらず、 この目的に多用されているLDAPサーバーである。従って、このIDMAP設定を、Sun iPlanet LDAP Server,Novell eDirectory, Microsoft ADS plus ADAMやその他で使うことは可能で ある。
ADSドメインのための例は、 LDAPを使うADSドメインメンバーサーバーにある。
Example 14.4. LDAPを使うADSドメインメンバーサーバー
NT4またはSamba-3形式のドメインの場合、realm
は使わず、
ドメインに参加するために使うコマンドはnet rpc join
である。
上記の例は、バグの報告に記述されている高度な
エラー報告のテクニックも示している。
MIT kerberosがインストールされている場合(バージョン 1.3.4以降)、以下の内容を
含むように/etc/krb5.conf
を編集する:
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = SNOWSHOW.COM dns_lookup_realm = false dns_lookup_kdc = true [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
Heimdal kerberosがインストールされている場合、/etc/krb5.conf
ファイルは空白にするか(すなわち内容が無い)、以下の内容を含むように編集する:
[libdefaults] default_realm = SNOWSHOW.COM clockskew = 300 [realms] SNOWSHOW.COM = { kdc = ADSDC.SHOWSHOW.COM } [domain_realm] .snowshow.com = SNOWSHOW.COM
Sambaは、/etc/krb5.conf
ファイルがない時はHeimdalライブラリを
使えない。それが空白のファイルであるならば、Heimdal kerberosライブラリは使用可能
である。SambaがHeimdalライブラリを使う時には、自動的にこれを見つけることが出来る
ので、特に何も設定しなくても良い。
以下のエントリを含むようにNSS制御ファイル/etc/nsswitch.conf
を編集する:
... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ...
この解決方法のためには、PADLの
nss_ldap
ツールセットが必要である。必要とされる情報を
/etc/ldap.conf
ファイルに設定すること。以下は、
動作するファイルの例である:
host 192.168.2.1 base dc=snowshow,dc=com binddn cn=Manager,dc=snowshow,dc=com bindpw not24get pam_password exop nss_base_passwd ou=People,dc=snowshow,dc=com?one nss_base_shadow ou=People,dc=snowshow,dc=com?one nss_base_group ou=Groups,dc=snowshow,dc=com?one ssl no
以下の手続きは動くようにするための設定手順である:
上記で示されたようにsmb.conf
ファイルを設定する。
上記で示されたように/etc/krb5.conf
ファイルを作成する。
上記で示されたように/etc/nsswitch.conf
ファイルを設定する。
PADL nss_ldapツールセットをダウンロードし、コンパイルし、インストールする。
上記で示されたように/etc/ldap.conf
ファイルを設定する。
LDAPサーバーを設定し、以下のLDIFファイルで示されるような、IDMAPによって 必要とされるトップレベルのエントリをディレクトリに追加(初期化)する。
dn: dc=snowshow,dc=com objectClass: dcObject objectClass: organization dc: snowshow o: The Greatest Snow Show in Singapore. description: Posix and Samba LDAP Identity Database dn: cn=Manager,dc=snowshow,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager dn: ou=Idmap,dc=snowshow,dc=com objectClass: organizationalUnit ou: idmap
Samba DMSをADSドメインに、以下のコマンドを使って参加させる:
root#
net ads testjoin
Using short domain name -- SNOWSHOW
Joined 'GOODELF' to realm 'SNOWSHOW.COM'
以下のようにして、Sambaのsecrets.tdb
ファイルに
LDAPサーバーへのアクセスパスワードを格納する:
root#
smbpasswd -w not24get
nmbd
, winbind
とsmbd
デーモンをこの順番で起動する。
ドメインへの参加が成功するか失敗するかを識別するため、この章の始めの方で 紹介された診断手続きに従うこと。多くの場合、失敗の理由が何も示されない コマンドプロンプトの静かな結果によって、失敗は表示される。
この方法はきれいなものではない。以下で提供される情報は手引きのみであり、かつ、 全くもって不確かで完全ではない。この方法は動く。数多くの巨大サイトで使用され、 耐えられるレベルのパフォーマンスを提供している。
smb.conf
ファイルの例は
NSS経由のRFC2307bisスキーマ拡張日付を使うADSドメインメンバーサーバー
にある。
DMSは通常の手順でドメインに参加しなければならない。更に追加で、PADL nss_ldap ツールセットのコンパイルとインストールが必要である。以下のようにしてこのツールを 構築する:
./configure --enable-rfc2307bis --enable-schema-mapping make install
/etc/nsswitch.conf
ファイル中には以下の内容が必要である:
... passwd: files ldap shadow: files ldap group: files ldap ... hosts: files wins ...
/etc/ldap.conf
も設定しなければならない。特定の説明に
ついては、PADLのドキュメントとnss_ldapのソースコードを参照のこと。
次のステップではADSスキーマの準備を必要とする。これは、この章の残りの部分で 簡単に説明する。
Microsoft Windows Service for UNIX (SFU)バージョン3.5は、Microsoftの Webサイトダウンロード から自由にダウンロードできる。このツールをダウンロードする必要はあり、 以下のMicrosoftの手順に従ってインストールする。
AD4UNIXツールの取得とインストールの手順は、 Geekcomix というWebサイトにある。
Table of Contents
Sambaがドメインを制御しているネットワーク中で、Windowsのユーザー、グループとマシン アカウントを管理するには、Microsoft Windowsネットワーク環境とUNIX OS環境の間で インタフェースを取る必要がある。Windows セキュリティドメインにマシンを追加するための 権利(許可)は、Windows NT4ドメインとActive Directoryドメインの両方で、非管理者ユーザーに 割り当て(設定)することができる。
ドメインへWindows NT4/2kX/XPProましんを追加するには、追加されるマシンごとにマシン アカウントを作成する必要がある。マシンアカウントは、ユーザーのログオンを許可する ために信頼できるマシンを検証するために使うのに必要である。
マシンアカウントはユーザーアカウントに類似していて、そのため、Sambaをホスティングしている
UNIXマシンでの実装では(すなわちSambaが動いているマシン)、ユーザーアカウントの特別なタイプ
として作成する必要がある。マシンアカウントは、通常のユーザーアカウントと比べて、
アカウント名(ログインID)が$
記号で終わっているところが異なる。
更に、このタイプのアカウントは、システムユーザーとしてUNIX環境に決してログイン出来ない
ことと、ログインシェルが/bin/false
に設定されていることと、ホーム
ディレクトリが/dev/null
に設定されていることも違う。マシンアカウントは
起動時にドメインメンバーのマシンであることを検証するためのみに使われる。このセキュリティ
対応は、ネットワークの完全性を破る中間者攻撃をブロックするために設計されている。
マシン(コンピュータ)アカウントは、ドメインメンバーサーバーとワークステーションのための セキュリティ証明書(credentials)を格納するために、Windows NT OSファミリで使われる。 ドメインメンバーの起動時、ドメインコントローラーと証明書の交換を含む検証プロセスを 行う。もしもドメインコントローラーが保持している証明書を使っての認証に失敗した 場合、マシンはドメインユーザーからのアクセスが出来なくなる。コンピュータアカウント は、Microsoft Windowsのセキュアな認証方法において必須のものである。
UNIXシステムアカウントの作成は、root
アカウントと言う方が通りがよい、
システム管理者の伝統的な唯一の権利であった。UNIX環境では、同じUIDを持つ複数のユーザーを
作ることが可能である。UID=0のUNIXユーザーはだれでもroot
アカウント
ユーザーと本質的に同じである。
すべてのバージョンのSambaは、UNIX環境で、ユーザー、グループとマシンアカウントを管理する
ためのCIFS機能呼び出しを許可するシステムインタフェーススクリプトを呼び出す。3.0.10
を含むそれまでのすべてのバージョンのSambaは、それらのインタフェーススクリプトを
実行するために、明確にUNIXのroot
アカウントにマップされる
Windows管理者アカウントを使用することを要求する。こうする必要性は、無理もない話だが、
特に、UNIXホストシステムでroot
レベルのアクセスを行ってはならない
人が特権を得てしまう事について、Samba管理者の間では評判が悪い。
Samba 3.0.11から、Windowsの権限モデルのサポートが導入された。このモデルは、特定の
権利をユーザーかグループSIDに割り当てるというものである。この機能を有効にするため、
smb.conf
ファイル中のglobal
セクション中で、
enable privileges = yesを定義しなければならない。
現在、Samba-3でサポートされている権利は“現在有効な権限の一覧”に一覧がある。 この章の残りでは、Sambaサーバー上でどのように権限を管理し使うかについて説明する。
Table 15.1. 現在有効な権限の一覧
権限 | 説明 |
---|---|
SeMachineAccountPrivilege | マシンをドメインに追加する |
SePrintOperatorPrivilege | プリンターの管理 |
SeAddUsersPrivilege | ドメインへのユーザーとグループの追加 |
SeRemoteShutdownPrivilege | リモートシステムの強制シャットダウン |
SeDiskOperatorPrivilege | ディスク共有の管理 |
SeTakeOwnershipPrivilege | ファイルか他のオブジェクトに対する所有権の取得 |
Sambaサーバー上でユーザーとグループに権利を割り当てる管理には2つの主要な手段がある。
止め引用のNT4ユーザーマネージャ
はSambaドメインコントローラーに接続
するためにWindows NT4、2000かXP Professionalのドメインメンバークライアントのどれから
でも使うことが出来、権限の割り当てを表示したり修正できる。しかし、このアプリケーション
は、Windows 2000かそれ以降のクライアント上で動かす時にはバグがある。そのため、管理
操作の実行を行うために必要なコマンドラインユーティリティを提供している。
Samba-3.0.11以降のnet rpc rights
ユーティリティは新しい3つの
サブコマンドを提供している:
引数なしで起動した場合、net rpc list
は単純にサーバー
上の有効な権利の一覧を表示する。特定のユーザーまたはグループを指定した
場合、ツールは指定されたアカウントに割り当てられている現在の権限を
表示する。accounts
という特別な文字列を付けて起動
した場合、net rpc rights list
はサーバー上のすべての
特権アカウントの一覧とそれに割り当てられた権利を表示する。
引数なしで起動すると、この機能は指定されたユーザーかグループに一連の 権利を割り当てるのに使う。例えば、Sambaドメインコントローラー上の Domain Admins groupのメンバーに、ドメインにクライアントマシンを追加する 能力を許可するためには、以下のように実行する:
root#
net -S server -U domadmin rpc rights grant \
'DOMAIN\Domain Admins' SeMachineAccountPrivilege
root#
net rpc rights grant 'DOMAIN\Domain Admins' \
SeMachineAccountPrivilege -S server -U domadmin
空白で区切った権利の一覧を指定することで、複数の権限を割り当てることも 可能である。パラメーター'Domain\Domain Admins'はシステムシェルによって バックスラッシュと空白が解釈されてしまうのを防ぐために、シングルクォート かダブルクォートで囲まなければならない。
このコマンドはnet rpc rights grant
と形式が似ている。
これは、ユーザーとグループから割り当てられた権利(か権利の一覧)を削除する。
、アカウントに割り当てられる権限の設定か削除を可能にするため、Domain Admins グループ メンバーとして接続する必要がある。この能力はDomain Adminsグループに固有で変更できない。 Domain Adminsのメンバーに割り当てられた能力以外、既定値の権利と権限はない。これは、 すべての管理者の権利と権限(それらに割り当てられた能力以外)は、Domain Adminsグループ でも明示的に割り当てられなければならないということを意味する。
いったんsmbdが、ユーザーが必要な権利を持っていると確認した場合、特定の操作はrootとして
実行されるので、初期状態では、どのユーザーに対しても、何らの権利は割り当てられない。
例えば、Windowsドメインにクライアントを参加させる時、add machine script
はほとんどの場合、スーパーユーザーの権利で動作させる必要がある。この理由のため、アカウントに
対して権限を割り当てるのはとても注意すべきである。
Samba-3.0.11で実装された権限は以下の通りである。ありそうではあるが、可能であれば、 この後のSambaのリリースで権限が追加実装されるかもしれない。また、現在実装されて いるが、使われていないものは、管理項目として将来のリリースで削除されるかも しれないので、それらの機能を使った時の成功/失敗はSambaメーリングリスト上で報告 することは重要である。
この権利は、net rpc user add
か、
NT4 User Manager for Domains
のような
ツール経由で新しいユーザーまたはグループアカウントを作成
するか否かをsmbdがユーザーに許可することを決める。
この権利を所有するアカウントは、 smb.conf
ファイル中で定義した
共有を追加/削除/変更
するコマンドをrootとして
実行出来る。このようなユーザーはSambaサーバー上のファイル共有に関連
づけられているACLを変更も出来る。
この権限はsmb.conf
ファイル中のprinter admin
オプションと、それがグローバルな権利であるという(プリンター単位毎ではない)
ことを除いて同じように動作する(セクション5のsmb.conf
マニュアルページ
参照)。結局smb.confのオプションは無効となり、プリンターへの管理者権限は
このオプションと、ntprinters.tdb
ファイル中にある
プリンターオブジェクトに対するセキュリティ記述子によって排他的に制御される。
Sambaはサーバーのシャットダウンと再起動のためと、直前に出されたシャット ダウンコマンドを中止するためののフックを提供する。この操作は通常OS によってrootユーザーにのみ制限されているので、上記のフックのどれかを使う ことができるアカウントはこの権利を持っていなければならない。
参照のために、Windows NT4 PDCで表示される権限は以下の通り:
SeCreateTokenPrivilege Create a token object SeAssignPrimaryTokenPrivilege Replace a process level token SeLockMemoryPrivilege Lock pages in memory SeIncreaseQuotaPrivilege Increase quotas SeMachineAccountPrivilege Add workstations to domain SeTcbPrivilege Act as part of the operating system SeSecurityPrivilege Manage auditing and security log SeTakeOwnershipPrivilege Take ownership of files or other objects SeLoadDriverPrivilege Load and unload device drivers SeSystemProfilePrivilege Profile system performance SeSystemtimePrivilege Change the system time SeProfileSingleProcessPrivilege Profile single process SeIncreaseBasePriorityPrivilege Increase scheduling priority SeCreatePagefilePrivilege Create a pagefile SeCreatePermanentPrivilege Create permanent shared objects SeBackupPrivilege Back up files and directories SeRestorePrivilege Restore files and directories SeShutdownPrivilege Shut down the system SeDebugPrivilege Debug programs SeAuditPrivilege Generate security audits SeSystemEnvironmentPrivilege Modify firmware environment values SeChangeNotifyPrivilege Bypass traverse checking SeRemoteShutdownPrivilege Force shutdown from a remote system
また、Windows 200x/XP ドメインコントローラーとワークステーションでサポートされている権限は以下の通り:
SeCreateTokenPrivilege Create a token object SeAssignPrimaryTokenPrivilege Replace a process level token SeLockMemoryPrivilege Lock pages in memory SeIncreaseQuotaPrivilege Increase quotas SeMachineAccountPrivilege Add workstations to domain SeTcbPrivilege Act as part of the operating system SeSecurityPrivilege Manage auditing and security log SeTakeOwnershipPrivilege Take ownership of files or other objects SeLoadDriverPrivilege Load and unload device drivers SeSystemProfilePrivilege Profile system performance SeSystemtimePrivilege Change the system time SeProfileSingleProcessPrivilege Profile single process SeIncreaseBasePriorityPrivilege Increase scheduling priority SeCreatePagefilePrivilege Create a pagefile SeCreatePermanentPrivilege Create permanent shared objects SeBackupPrivilege Back up files and directories SeRestorePrivilege Restore files and directories SeShutdownPrivilege Shut down the system SeDebugPrivilege Debug programs SeAuditPrivilege Generate security audits SeSystemEnvironmentPrivilege Modify firmware environment values SeChangeNotifyPrivilege Bypass traverse checking SeRemoteShutdownPrivilege Force shutdown from a remote system SeUndockPrivilege Remove computer from docking station SeSyncAgentPrivilege Synchronize directory service data SeEnableDelegationPrivilege Enable computer and user accounts to be trusted for delegation SeManageVolumePrivilege Perform volume maintenance tasks SeImpersonatePrivilege Impersonate a client after authentication SeCreateGlobalPrivilege Create global objects
SambaチームはUNIX/Linux環境で論理的に問題が無く、有用な権限のみを実装している。 Windows 200X/XPにおける権限の多くはUNIX中のものに直接相当するものは無い。
すべてのWindows NT4とそれ以降のサーバーはdomain Administratorアカウントを必要とすることに 注意。Sambaバージョン3.0.11以降は、割り当てられた権利と権限 (ユーザーの権利と権限を参照)経由で管理者の任務を実行する ことを許可する。サーバーのpassdbバックエンド中のアカウントは、よく知られている既定値の 管理者アカウントのRIDに設定できる。Sambaドメインコントローラー上のドメインSIDを得る ためには、以下のコマンドを実行する:
root#
net getlocalsid
SID for domain FOO is: S-1-5-21-4294955119-3368514841-2087710299
以下のように、pdbedit
を使ってアカウントにドメイン管理者のRIDを
割り当てても良い:
root#
pdbedit -U S-1-5-21-4294955119-3368514841-2087710299-500 -u root -r
500というRIDの値は、よく知られた既定値のAdministratorアカウントの標準値である。これは、 Windowsマシン上かドメイン上のAdministratorアカウントが持つ権利と権限を割り当てるRIDで ある。UNIX/Linux環境下では、同等なものはUID=0(rootアカウント)である。
Sambaバージョン 3.0.11以降のリリースでは、WindowsのユーザーかWindowsのグループアカウントの ために設定された権利と権限と同等のものを提供するAdministratorアカウントなしで動作させる ことが可能である。
Windows NT4(とそれ以降)のクライアントがドメインに参加したとき、ドメイン全体での
Domain Admins
グループはクライアント上のローカルな
Administrators
グループのメンバーシップに追加される。ドメイン
グローバルのDomain Admins
グループのメンバーであるユーザーは誰でも
Windowsクライアント上で管理者の権利と権限を持つ。
これは、ユーザーがドメインサーバー上でも管理者の権利と権限を持ってしまうために、
必ずしもすべての場合において良い解決方法とは言えない。Windowsクライアント上の
Power Users
グループはワークステーションのみのローカルな
管理者権限を持つ。任意のグローバルユーザーかドメイングローバルグループは、
ローカルワークステーションのPower Users
グループのメンバーに
追加できる。
ネストされたグループのサポートに、Windows
ワークステーション上でのローカルグループにドメインユーザーとグループを追加する
方法の例がある。Sambaサーバーからnet
を使うことで、この作業が
行える。
これを行う別の方法は、WindowsワークステーションにAdministrator
としてログオンし、cmd
シェルを開き、以下を実行する:
C:\>
net localgroup administrators /adddomain_name\entity
ここで、entity
は、ドメインユーザーかドメイングループのアカウント名である。
Table of Contents
慣れたMicrosoft Windowsユーザーは、期待しているようにはSamba経由で共有されている、 ファイル、ディレクトリと共有リソース操作が動かないことに、しばしば当惑する。 Microsoft Windowsネットワーク管理者は、ネットワークのアクセス制御と、未認証の アクセスからリソースを保護する時に、ユーザーが必要とするアクセスを提供する方法 についてしばしば当惑している。
多くのUNIX管理者は、Microsoft Windows環境には慣れておらず、ファイルとディレクトリの アクセスパーミッションを設定しようとするMicrosoft Windowsユーザーが望むことを図式化する ことに困難が生じている。
問題は、2つの環境の間で、ファイルとディレクトリのパーミッションと制御がどのように動くかの 違いにある。この違いは、その大きな違いに橋を架けようとしても、Sambaが完全にはそれを 隠せないということにある。
POSIX ACL技術は、現在有意義な使用の例があまりないにもかかわらず、長い期間UNIX用に (拡張属性と共に)提供されてきている。これは、商用Linux製品で、ACLの適用が遅い理由 について、ある程度の説明になる。Microsoft Windows管理者にとっては、Microsoft Windows NT において10年以上も前から基本的な機能としてACLが提供されていることを鑑みると、 このことは驚くべきことである。
この章の目的は、Microsoft Windowsデスクトップユーザーに対して、最も良い環境を提供する ための、最適の方法を見つけるためにネットワーク管理者を手助けする、Samba-3で可能な、 各制御の要点を提供することである。
これは、異なったOS環境での相互運用性とデータの交換を提供するためにSambaが作成した ことを説明するのに良い機会である。SambaはMicrosoft Windowsのようなプラットフォームに UNIX/Linuxを変化させるつもりはない。その代わり、2つの環境間で、十分なレベルでデータの 交換を提供することを目的としている。現在利用可能なものは、当初の計画と希望から大きく 拡大していているが、それでもギャップは縮み続けている。
Sambaはファイルシステムアクセス管理に多くの自由度を提供する。現在のSambaでは キーとなるアクセス制御機能が提供されている:
Sambaアクセス制御機能
SambaはUNIXファイルシステム制御を実装し、それを使う。Samba サーバーにアクセスするユーザーは特定のMicrosoft Windowsユーザーとして そうする。この情報はログオンか接続のセットアップ手順の一部として Sambaサーバーに渡される。Sambaはこのユーザー識別情報を、ファイル システムリソース(ファイルとディレクトリ)へのアクセス許可を与える かどうかを検証するために使う。この章では、UNIXパーミッションと 制御が少々奇妙か未知な人について、概要を提供する。
Sambaの共有定義
共有の設定と制御をsmb.conf
ファイル中で設定するとき、ネットワーク
管理者は本来のファイルシステムのパーミッションと動作を上書き設定
することが出来る。これはMicrosoft Windows NTユーザーがより期待する
ような動作を引き起こすために有用かつ便利であるが、それに到達する
最も良い方法は滅多にない。基本的なオプションと
テクニックはここで説明されている。
共有それ自身に対するACLの設定がMicrosoft Windows NTで可能なように、 Sambaでもそれは可能である。この機能を使う人は少ないが、アクセス 制御(制限)に影響を与えるために簡便な方法の一つとして残っている ことと、他の方法と比較して最小の影響でしばしばそれを行うことが できる。
UNIX POSIX ACLを経由したMicrosoft Windows ACL
UNIX/Linux上でPOSIX ACLを使う場合は、ベースとなるOSがそれをサポート している場合にのみ可能である。もしもそうでない場合、このオプションは 有効ではない。現在のUNIX技術基盤ではPOSIX ACLを標準サポートしている。 このサポートを提供するLinux kernelへのパッチも存在する。残念なことに、 Linuxプラットフォームの一部のみがネイティブなACLと拡張属性を有効にして 現時点で提供を行っている。この節では、それをサポートしているプラット フォームのユーザーに対する関連情報が記述されている。
おそらく、最も重要な認識される点は、UNIX OS環境で提供されているものと、Microsoft Windows NT4/200x/XP におけるフィルシステムの技術の実装が完全に異なるという単純な事実である。最初に最も 有意義な違いが何かを考え、次にその違いを乗り越えるためにSambaが何をしているかを見てみる ことにする。
SambaはUNIXファイルシステムの上で動作する。これは、UNIXファイルシステムの 取り決めとパーミッションの適用を受けることを意味する。また、もしも Microsoft Windowsネットワーク環境がファイルシステムの動作を要求するならば、 それはUNIXファイルシステムの動作とは異なり、何らかの方法でSambaは透過的かつ 一貫した方法でエミュレートを行う。
Sambaがこれをかなりの部分、それらの最上位で、既定値の動作を上書きする高度な
オプションの設定を提供するという良いニュースがある。いくつかの上書きについて
説明はあるが、大部分は既定値の動作の範囲内にとどまっている。制御可能性の詳細な
点について知りたい場合は、smb.conf
マニュアルページを調べること。
以下では、UNIXファイルシステムの機能とMicrosoft Windows NT/200xを比較する:
Microsoft Windows NT4/200x/XPのファイル名は254文字まで有効だが、UNIX ファイル名は1023文字まで大丈夫かもしれない。Microsoft Windows中で、 ファイルの拡張子は特定のファイルタイプを意味する。UNIXではすべての名前が 任意であると考えられるので、これは厳格には見かけない。
Microsoft Windowsがフォルダーと読んでいるものは、UNIXではディレクトリである。
Microsoft Windowsファイル名は8.3形式(8文字のファイル名と3文字の拡張子)の 場合、一般的に大文字である。8.3形式より長いファイル名は、大小文字を保持 するが、それは無視される。
UNIXのファイルとディレクトリ名は大文字小文字を区別し、その状態は保存 される。SambaはMicrosoft Windowsファイル名の動作を実装しているが、それは ユーザーアプリケーションとしてである。UNIXファイルシステムは大文字小文字を 無視したファイル名の検索を実行する機能は提供していない。Microsoft Windows はこれを既定値で行う。これは、UNIX OS環境で標準としては備わっていない 機能を提供するために、処理のオーバーヘッドがかかってしまうと言うことである。
以下の例を考えてみる。以下はUNIX名としては一意だが、Microsoft Windows ファイル名としては同一である:
MYFILE.TXT MyFile.txt myfile.txt
明らかに、Microsoft Windowsファイルの名前空間ではこれらの3つのファイルは 同時に存在できないが、UNIXではできる。
もしも上記3つがすべて存在していたときにSambaは何をすべきか? 辞書的に最初のものがMicrosoft Windowsユーザーから見えるようにすることで ある。残りは見えず、アクセスも出来ない。それ以外の解は自殺的 行為である。Windowsクライアントは大文字小文字を区別しないファイル検索を 要求するため、大文字小文字を区別しないファイルの一覧に一致する、 複数のファイルがあるUNIXディレクトリの場合、Sambaは一貫した選択方法を 提供しなければならないということになる。
Microsoft Windows とDOSはディレクトリの区切り文字としてバックスラッシュ
\
を使い、UNIXでは通常のスラッシュ/
をディレクトリの区切り文字として使う。これはSambaによって透過的に扱われる。
Microsoft Windows製品は、ディレクトリのパーティションを表現するために、
C:
のようなドライブレターの概念を持つ。UNIXはファイルの
パーティションに対して分離された識別子を持つという概念がない。そのような
各ファイルシステムはディレクトリツリー全体の一部としてマウントされる。
UNIXディレクトリツリーは、C:\
のような、DOSの
ドライブのrootを指定するような形で、/
から始まる。
Microsoft Windowsは一般的に先頭がドット(.
)で始まる
ファイル名は使わないがUNIXの場合、はユーザーのホームディレクトリ中では
当たり前のように使われている。ドット(.
)で始まる
ファイルは通常多くのUNIXアプリケーションの起動ファイルか、スタートアップ
設定データを含むファイルである。
Microsoft Windowsは、実際の位置にあるファイルに対してそのファイルを実行する ためにリダイレクトを行う、特別なタイプのファイルとして振る舞う リンクとショートカットを使う。UNIXでは、ファイルと ディレクトリのリンクを使うが、それはMicrosoft Windowsユーザーが使っているもの とは全く異なる。
シンボリックリンクは、UNIX中ではデータ(ファイル又はディレクトリ)の実際の 位置を含むファイルである。(読み出しあるいは書き込みのような)操作は参照 されたファイルに対して直接行われる。シンボリックリンクは “ソフトリンク”としても参照される。ハードリンクはMicrosoft Windowsではなじみのないものである。これは、1つの物理的なファイルを、複数の ファイル名で同時に参照できるようにするものである。
Microsoft Windows管理者が、UNIX/Linuxを理解するようになるプロセス中で、一時的に 若干当惑することを引き起こすかもしれな微妙な違いがある。それらは、UNIX/Linuxの トレーニングと教育の目的としての専用のテキストを見ると良い。
ディレクトリ操作には3つの基本的な操作がある。それは作成
,
削除
,改名
である。
UNIXとWindowsによるディレクトリの管理
では、WindowsとUNIX中でのコマンドにおける、上記の操作の実装について比較している。
Table 16.1. UNIXとWindowsによるディレクトリの管理
動作 | Microsoft Windowsのコマンド | UNIXのコマンド |
---|---|---|
create | md folder | mkdir folder |
delete | rd folder | rmdir folder |
rename | rename oldname newname | mv oldname newname |
ネットワーク管理者は、ファイルとディレクトリのパーミッションのメンテナンスに 関連する、基本的なUNIX学習マニュアルとリファレンス資料を読むことを強く推奨する。 POSIX ACLや拡張属性(EA)のようなより複雑な機能に訴求しない基本的なUNIXの パーミッションについて多くの説明がある。
UNIX/Linuxのファイルとディレクトリアクセスパーミッションは3つの主要なデータの設定と 1つの制御の設定がある。UNIXでのファイル一覧は下記のようになる:
$
ls -la
total 632 drwxr-xr-x 13 maryo gnomes 816 2003-05-12 22:56 . drwxrwxr-x 37 maryo gnomes 3800 2003-05-12 22:29 .. dr-xr-xr-x 2 maryo gnomes 48 2003-05-12 22:29 muchado02 drwxrwxrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado03 drw-rw-rw- 2 maryo gnomes 48 2003-05-12 22:29 muchado04 d-w--w--w- 2 maryo gnomes 48 2003-05-12 22:29 muchado05 dr--r--r-- 2 maryo gnomes 48 2003-05-12 22:29 muchado06 drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08 ---------- 1 maryo gnomes 1242 2003-05-12 22:31 mydata00.lst --w--w--w- 1 maryo gnomes 7754 2003-05-12 22:33 mydata02.lst -r--r--r-- 1 maryo gnomes 21017 2003-05-12 22:32 mydata04.lst -rw-rw-rw- 1 maryo gnomes 41105 2003-05-12 22:32 mydata06.lst$
1行の中の各項目は(左から右に)パーミッション、ファイルのハードリンク数、所有者、 グループ、サイズ(バイト)、アクセス日付、最終更新日付とファイル名である。
パーミッション欄の概要はUNIXパーミッション欄の概要 にある。
どのビットフラグもOFFにできる。OFFになったフラグは"できない"と同値で、 “-”文字で表現される(“サンプルファイル”を参照)。
Example 16.1. サンプルファイル
-rwxr-x--- 意味: ^^^ 所有者(ユーザー)はこのファイルを読み、書き、実行できる。 ^^^ グループに属したユーザーは読み、実行できる。 ^^^ それ以外のユーザーはこのファイルに対して何も出来ない。
[タイプ]フィールドにはさらに別の意味もあり、それは、c = キャラクターデバイス、 b = ブロックデバイス、p = パイプデバイス、s = UNIXドメインソケットである。
文字rwxXst
はユーザー、グループとその他に対して、読み出し(r)、
書き込み(w)、実行(あるいはディレクトリへのアクセス許可) (x)、ファイルが
ディレクトリかすでにあるユーザーに対して実行許可を与えられた場合に実行可能(X)、
実行時にset user ID (SUID)か set group ID (SGID) (s)かスティッキー(t)である。
スティッキービットがディレクトリ上に設定された場合、そのディレクトリ内にある
ファイルは、rootか所有者のみunlink(削除)か改名できる。スティッキービットがない
場合、書き込み可能なディレクトリでは、誰でもファイルの削除や改名が出来る。
スティッキービットは、誰でも書き込み可能な、/tmp
のような
ディレクトリでは一般的に使われる。
setuidやsetgidビットがディレクトリに設定された場合、その中に作成された ファイルは、setuidビットsetgidビットのいずれが設定されたかに応じて、ディレクトリの 所有ユーザーたはグループによって所有される。これは、あるグループに所属している すべてのユーザーがファイルの読み書きをできるようにすることが望ましく、これらの ユーザーが所属しているものと異なるプライマリグループを持つユーザーが、該当の ファイルを排他的に所有してしまうことが望ましくないようなディレクトリの パーミッションを設定する際に有効なことがあろう。
ディレクトリがd-wx--x---
に設定された時、所有者はその中の
ファイルを読んだり作成(書き込み)出来るが、読み出し(r)フラグが設定されていない
ので、だれも、ファイルの一覧を表示(見る)事が出来ない。グループに属するユーザーは
そのディレクトリ中のファイルを読めるが新しいファイルは作成できない。もしも、
ディレクトリ中のファイルがグループに対して読み書き可能なように設定された場合、
グループメンバーはそれらに書き込み(または削除)ができる。
どのように、ユーザーの削除操作から、ファイルやディレクトリを保護したらよいか、 という事についてSambaメーリングリストに質問が来ることがある。例えば、Windows NT/2K/XP は、ディレクトリ配下に、ファイルを書くことは出来るが削除できないというアクセス制御を 設定する機能がある。これは、ファイルに書き込みは出来るが、削除は出来ないというACLを Windows上で設定することで可能になる。このような考え方はUNIX OSファイル空間ではない。 UNIXファイルシステムでは、ファイルを作成出来るユーザーはファイルに書き込みが出来る。 ファイルがあるディレクトリへの書き込み権があり、ファイルへの書き込み権があるユーザーは それを削除できてしまう。
確認ではあるが、UNIX環境では、ファイルの削除はそのファイルがいるディレクトリの パーミッションによって制御される。別の言い方をすると、対象となるファイルの 所有者ではなくても、書き込み権があるユーザーは、ディレクトリ中のファイルを 削除できる。
必要に応じて、SambaはホストOSのファイルシステムの構造を受け取る。Sambaは Windows ACLを有効にすることについてと"最も最適な"POSIX ACLへの変換実行に ついては、ファイルシステムの能力に制限される。いくつかのUNIXファイルシステム では、拡張属性と呼ばれている機能をサポートしている。Windowsでの 継承という概念のみ、適切な拡張属性を使ってSambaは 実装している。
拡張属性の特定の動作は、UNIXと例えばLinuxのようなUNIX風のシステム全体には
一貫していない。例えば、ディレクトリやファイルを削除操作から防ぐためのフラグを
セットすることは、拡張属性の特定の実装では可能である。これを達成する拡張属性は
immutable
ビットと呼ばれている。残念なことに、immutable
フラグの実装は公開された文書とは一致していない。たとえば、SuSE Linux 9.2上の
chattr
のマニュアルには:
A file with the i attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute. (訳: i 属性を持つファイルは変更できない:削除も改名もこのファイルへの リンク作成も出来ないし、このファイルへの書き込みも出来ない。スーパー ユーザーかCAP_LINUX_IMMUTABLE機能を所有するプロセスがこの属性を設定 および削除できる)。
immutable フラグが、Sambaが動いているファイルシステム上でサポートされているか、 簡単なテストは以下のように出来る。
Procedure 16.1. ファイルの Immutibilityサポートのテスト
filename
という名前のファイルを作成。
root
ユーザーとしてログインし、以下のようにimmutibileフラグをテストファイルに設定:
root#
chattr +i `filename'
ファイルを所有しているユーザー(非root)でログインし、以下のようにしてファイル削除を試みてみる:
mystic:/home/hannibal > rm filename
immutableが正しく効いているならばファイル削除は出来なくなっている。
immutable bitをサポートしているファイルシステムがあるOS上では、ディレクトリを 作成できるが削除できないようにするのは可能である。immutableディレクトリが書き込み 可能かどうかを、そのホストシステム上のマニュアルページでチェックすること。 もしも出来なければ、ディレクトリ全体とその内容は、書き込み(ファイル作成も)と 削除から効果的に保護される。
smb.conf
セクション中の以下のパラメーターは、共有の制御かアクセス制御の設定を
定義する。以下のオプションのどれかを使う前に、smb.conf
のマニュアルページを
参照のこと。
ユーザーとグループベースの制御はとても便利なことがわかっている。ある特定の状態に おいては、単一のユーザーが行うような形で、すべてのファイルシステムへの操作を強制する ことはとても望ましいことがある。force userと force groupの動作を使うとこれを行う事ができる。 他の状態においては、特定の認証された人のみが共有またはその内容にアクセス出来る ようにさせるような、偏執的なレベルの制御を使うことが必要かもしれない。これには、 valid usersかinvalid users パラメーターが便利である。
いつものように、管理するためと、アクセスを制御する方法の不明確な点を最小化する、 一番簡単な方法を使うことを特に推奨する。覚えていてほしいが、状態をそのまま残すと、 他の誰かが手助けを提供する必要があり、もしもだれかが、あまりにも大きな混乱状態 を見つけるか、何をしていたかが理解できない場合、Sambaが削除され、別の解が適用 されてしまうと言う危険性が出てくる。
ユーザーとグループベースの制御は上記の制御について列挙している。
Table 16.2. ユーザーとグループベースの制御
制御パラメーター | 説明、動作、備考 |
---|---|
admin users | 共有に対して管理者権限を許可するユーザーの一覧。そのユーザーは スーパーユーザー(root)と同様すべてのファイル操作ができる。 この一覧中のユーザーは共有上でファイルのパーミッションに関わらず 何でも出来る。 |
force group | このサービスに接続するすべてのユーザーに既定値のプライマリグループ として割り当てるUNIXのグループ名を指定する。 |
force user | このサービスに接続するすべてのユーザーに既定値のユーザーとして 割り当てるUNIXのユーザー名を指定する。 これは、ファイルの共有に便利である。間違って使うとセキュリティ 上の問題が発生する。 |
guest ok | もしもパラメーターがサービスに対して接続されたならば、サービスに 接続する時にパスワードが不要になる。権限は guestアカウントになる。 |
invalid users | このサービスにログイン出来ないユーザーのリスト。 |
only user | 接続を許可しないユーザー名の一覧。 |
read list | サービスに対してリードオンリアクセスを許可するユーザーの一覧。 この一覧中のユーザーはリードオンリオプションがどのように設定 されていても、書き込み権はない。 |
username |
詳細は |
valid users | サービスにログイン出来るユーザーの一覧。 |
write list | サービスに読み書き可能なアクセスが出来るユーザーの一覧。 |
ディレクトリパーミッションベースの制御は、間違って使った場合、間違った設定の 原因を診断するのにかなりの困難が生じる。控えめに、そして厳重に使うこと。 徐々に、1つずつ、おのおのを導入すると、好ましくない副作用が見つかるかもしれない。 問題発生時には、いつでもそれらをコメントアウトし、徐々に様子を見ながらそれらを 元に戻していく。
ファイルとディレクトリパーミッションベースのアクセス制御を使うためのパラメーターに 関連する情報は、 ファイルとディレクトリパーミッションベースの制御 を参照のこと。
Table 16.3. ファイルとディレクトリパーミッションベースの制御
制御パラメーター | 説明、動作、備考 |
---|---|
create mask |
|
directory mask | UNIXディレクトリを作成する時に、DOSのモードをUNIXのモードに 変換する時に使う8進のモード値。directory security maskも参照。 |
dos filemode | このパラメーターを有効にすると、ファイルに書き込み権があるユーザーに そのパーミッションの変更を許可する。 |
force create mode | このパラメーターは、Sambaによって作成されたファイル上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。 |
force directory mode | このパラメーターは、Sambaによって作成されたディレクトリ上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。 |
force directory security mode | Windows NTクライアントがディレクトリ上のUNIXパーミッションを操作 する時に変更されるUNIXパーミッションビットを制御する。 |
force security mode | Windows NTクライアントがUNIXパーミッションを操作する時に変更 されるUNIXパーミッションビットを制御する。 |
hide unreadable | 読めないファイルを、クライアントから見えなくする。 |
hide unwriteable files | 書き込めないファイルをクライアントから見えなくする。書き込めない ディレクトリは通常通り見える。 |
nt acl support | このパラメーターはsmbdがUNIXパーミッションをWindows NT ACLにマップ するかどうかを制御する。 |
security mask | Windows NTクライアントがファイル上のUNIXパーミッションを操作する 時に変更されるUNIXパーミッションビットを制御する。 |
他の制御中に記載があるパラメーターはファイルアクセスへの
不注意によるバリアを作成する方向で、管理者によってしばしば使われる。それらは、
smb.conf
のファイル設定の完全な影響がわからない結果である。
The parameters documented in Other Controls are often used by administrators
in ways that create inadvertent barriers to file access. Such are the consequences of not understanding the
full implications of smb.conf
file settings.
Table 16.4. 他の制御
制御パラメーター | 説明、動作、備考 |
---|---|
case sensitive, default case, short preserve case | これは、すべてのファイル名検索を大文字小文字を意識した形で行う 事を意味する。Microsoft Windowsくらい亜入おから受け取った正確な 名前で、ファイルはSambaによって作成される。 |
csc policy | クライアントサイトのキャッシングポリシーは、Microsoft Windowsの クライアントサイドのファイルキャッシング機能に類似している。 |
dont descend | 常時空白としてサーバーが見せる、カンマで分離されたディレクトリ一覧を指定する。 |
dos filetime resolution | このオプションは、Samba共有に対して、主にVisual C++との互換オプションとして使われる。 |
dos filetimes | ファイルに書き込みが出来るときにDOSとWindowsは、ユーザーにファイルの 時刻変更を許可する。POSIXでの流儀ではこれは出来ない。このオプションは DOSとWindowsの流儀を許可する。 |
fake oplocks | Oplocksは、SMBクライアントがサーバーから、ファイル操作をローカルに キャッシュする許可を得る方法である。もしもサーバーがoplockを許可 すると、クライアントは、ファイルへのアクセスが唯一であると仮定 することから自由になり、ファイルのデータをより頻繁にキャッシュする。 |
hide dot files, hide files, veto files | 注意:Microsoft Windowsエクスプローラーはhiddenが設定されたファイルの 状態を無視するので、結局それは見えてしまう。 |
read only | このパラメーターがyesの場合、サービスのユーザーはサービスのディレクトリ 中のファイルを作成又は変更できない。 |
veto files | 見えないか、アクセスできないファイルとディレクトリの一覧。 |
この節では、Sambaの共有単位でのアクセス制御における制限の設定方法について取り
扱う。既定値では、Sambaは共有自身には何らの制限も設定しない。共有自身への
制限は、Microsoft Windows NT4/200x/XP共有上で設定出来る。これは、共有に
接続する人を効果的に制限できる方法である。特定の制限がない場合、既定値の
設定はグローバルユーザーに対してEveryone - フルコントロール
(フルコントロール、変更と読み出し)である。
現時点ではSambaは共有上のアクセス制御の設定を行うためのツールを提供していない。 それらの設定を作成する唯一の方法は、NT4のサーバーマネージャか Windows 200xの、コンピュータの管理のための、Microsoftマネジメントコンソール (MMC)を使うことである。Sambaのコマンドラインツールでこの機能を提供することは 現時点では予定されていない。
Sambaはshare_info.tdb
というファイル中に共有単位のアクセス
制御の設定を格納する。サーバー上にこのファイルがある場所は、Sambaがコンパイル
された状態に依存する。Sambaのtdbファイルがある既定値の位置は、
/usr/local/samba/var
配下である。もしもtdbdump
ユーティリティがコンパイルされシステム中にインストールされているならば、
tdbファイルがあるディレクトリ中でtdbdump share_info.tdb
を
実行する事によってこのファイルの内容を検査することが出来る。
共有のパーミッションの管理を行うための最適のツールはプラットフォーム 依存である。環境に応じて最適のツールを選択されたい。
Windows NT4 ワークステーションかサーバーからSambaサーバー上の 共有のパーミッションを管理するのに必要なツールは、 NT サーバーマネージャである。サーバーマネージャはWindows NT4 サーバー製品とともに出荷されているが、Windows NT4ワークステーション には付いていない。Microsoft Windows NT4 ワークステーション 用のNT サーバーマネージャは、MicrosoftのWebサイト support から入手できる(訳注:日本語版は こちらから)。
Microsoft Windows NT4/200x/XP上では、 共有のACLはMicrosoftエクスプローラーのようなツールで設定する。 たとえば、Windows 200xでは、共有フォルダーを右クリックし、次に、 を選択し、次に パーミッションをクリックする。 Windows NT4/200xでの既定値のパーミッションはグループ "Everyone"が共有に対してフルコントロールを持つようになっている。
Microsoft Windows 200xとそれ以降のバージョンでは、MMCに対して コンピュータの管理スナップインと 呼ばれるツールが提供されている。このツールは、 経由でアクセス出来る。
Procedure 16.3. 手順
MMCのコンピュータマネジメントスナップインを起動後、メニュー項目 別のコンピュータに接続(C)を選択する。もしも、 ドメインにログオンしていない場合、ドメインログオンユーザー名と パスワードを聞いてくるので入力する。それでドメインの認証を行う。 もしも管理者権限でログインしているならば、このステップは省略される。
をクリックし、もしも、Sambaサーバーがコンピュータを選択 ボックス中に表示されていないならば、Name: フィールド中に対象のSambaサーバーの名前を入力する。次に システムツールのそばにある をクリックし、左パネル中の 共有フォルダーのそばにある をクリックする。
右パネル中でアクセス制御のパーミッションを設定したい共有上で 右クリックする。次に、共有のパーミッション を右クリックする。これで、小浮遊フォルダーにアクセス制御 エンティティを追加できる。各エントリに割り当てたいアクセスの タイプ(フルコントロール、変更、読み込み)を覚えておくこと。
注意深く作業する必要がある。このユーザーを削除しないで
Everyone
ユーザーからすべてのパーミッションを
取り去ると、この共有に対しては誰もアクセス出来なくなる。これは
ACLの優先順位として知られていることの結果である。Everyoneに
対してアクセス権なしということは、
Everyone
のグループに属している
MaryK
というユーザーは、明示的な、フルアクセス
の権利を与えられたとしても、アクセスできない。
Windows NTクライアントは、基盤となるUNIXパーミッションを表示したり変更 するための、ネイティブなセキュリティ設定ダイアログボックスを使うことが できる。
この機能は、Sambaが動作しているUNIXホストのセキュリティを危うくしない ように留意し、かつ、Samba管理者が設定出来るすべてのファイル パーミッションルールに依然として従う。
SambaはPOSIX ACLの範囲内で動くので、種々の、Windowsで提供されている よりきめ細かいアクセス制御は実際の所無視される。
Samba経由での、UNIX/LinuxシステムファイルへのすべてのアクセスはOSの ファイルアクセス制御によって制御される。ファイルアクセスの問題を理解 しようとする時、Sambaによってファイルアクセスを行う時に提供されるWindows ユーザーの識別子を見つけることはきわめて重要である。これは、Sambaのログ ファイルから見つけるのが最も良い。
NT4/200x/XPクライアントからSambaでマウントしたドライブレターかUNCパス 中のファイルかディレクトリのどれかを右クリックする。メニューがポップ アップするのでメニューの最下部にあるプロパティ エントリをクリックする。この動作でファイルのプロパティ ダイアログボックスが上がってくる。セキュリティタブを クリックすると3つのボタンが表示される: 、 と である。 ボタンは、ユーザーがNTの管理者でない場合、 "要求された権限をクライアントが持っていません(A requested privilege is not held by the client)" というエラーメッセージを表示するか、ユーザーがNT管理者としてログオンしている 場合、ファイルに対する監査要求を追加するために、管理者に許可を行う ダイアログを表示する。このダイアログは現時点ではSamba共有には機能しない ので、唯一使えるボタンである ボタンは、 表示されているユーザーの一覧を現時点では許可出来ない。
ボタンをクリックすると、ダイアログボックスが 表示され、そのファイルの所有者を表示する。所有者は以下のように表示される:
SERVER\user (長い名前)
ここでSERVER
はSambaサーバーのNetBIOS名である。
user
はこのファイルを所有しているUNIXユーザー
のユーザー名であり、(長い名前)
はユーザーを識別
するための説明文字列である(通常はUNIXパスワードデータベースのGECOS
フィールドが使われる)。 ボタンをクリック
して、このダイアログを閉じる。
もしもnt acl supportパラメーターが
false
に設定されているならば、ファイルの所有者は
NTユーザーのEveryoneとして表示される。
ボタンでは異動したい先の人がこの ファイルの所有権を取得することは出来ない(それをクリックすると、現在 NTクライアントにログオンしているユーザーが見つからないということを通知する ダイアログボックスが表示される)。この理由は、ファイルの所有者の変更は、 UNIX上では特権操作であり、rootユーザーにのみ許可されて いるからである。このボタンをクリックすると、NTに対してNTクライアントに ログオンしている現在のユーザーにファイルの所有者を変更するようにNTに指示 するが、これは現時点ではSambaでは動作しない。
NTにあるchown
コマンドはSambaでも動作し、rootとして
Sambaサーバーに接続している管理者権限を持つユーザーに、ローカルのNTFSファイル
システムとリモートマウントしたNTFSかSambaドライブの両方のファイルの所有者
の変更を許可する。これは、Sambaチームの一員であるJeremy Allisonによって
書かれたNTセキュリティライブラリであるSeclibの
一部として提供されていて、これはSambaのFTPサイトからダウンロードできる。
3番目のボタンは
である。これをクリックすると、 パーミッションとファイルかディレクトリのUNIXでの所有者の両方を表示する ダイアログボックスが起動する。所有者は以下のように表示される:SERVER
\
user
(長い名前)
SERVER
はSambaサーバーのNetBIOS名であり、
user
はファイルを所有しているUNIXユーザーの
ユーザー名であり、(長い名前)
は、ユーザーを識別
する説明文字列である(通常はUNIXパスワードデータベースのGECOSフィールドが
使われる)。
もしもnt acl supportパラメーターが
false
に設定されている場合、ファイルの所有者は
Everyone
というNTユーザーとして表示され、パーミッション
はNTのフルコントロールとして表示される。
パーミッション欄はファイルとディレクトリでは異なって表示される。詳細は次項で説明する。
標準のUNIXユーザー/グループ/その他の三つ組みと、それに対応する
読み、書き、実行
パーミッションの三つ組みは、Sambaによって
“r”, “w”, と “x”ビットが対応するNT
パーミッションにマップされる、NT ACLのパーミッションの3つの要素にマップされる。
UNIXの「その他」パーミッションは、UNIXの世界で許可されるパーミッションのリストを
伴ってグローバルNTグループのEveryone
にマップされる。
UNIXの所有者とグループパーミッションは、それぞれUNIXのユーザーとグループに
許可されるパーミッションのリストを伴って、NTのユーザーアイコンと
NTのローカルグループアイコンとして表示される。
多くのUNIXパーミッションのセットが、たとえば読み込み
、
変更
, あるいは フルコントロール
のような共通のNTの名前にマップしないという理由で、通常パーミッションは
NTの表示リスト中で特殊なアクセス許可
という単語が
前に付く。
しかし、もしもファイルに、特定のUNIXユーザー、グループ、その他に対して何も
許可しないパーミッションが付いているとどうなるだろうか?
アクセス権なしを見えるように、かつ変更できるように
するため、Sambaは所有権の取得
というNTのACL属性を
上書きし(UNIXでは何の意味もない)、NTのO
ビットを設定
して、アクセス権なしというコンポーネントを報告する。これはもちろん、
それを0のようにするために選ばれ、結局アクセス権なしの意味になる。
この動作の背景にある結論についての詳細は、以下に記述がある。
NT NTFSファイルシステム上のディレクトリは、2つの異なったパーミッションの
組を持っている。最初の組は、通常のRW
NT形式中での
最初の括弧の組中に表示される、ディレクトリそれ自身上のACLセットである。
このパーミッションの最初の組は通常のファイルのパーミッションに対して、
上記で説明があったようなのと正確に同じ方式で、Sambaによって作成され、
同じ方法で表示される。
2番目のディレクトリパーミッションの組はUNIXパーミッションの世界では実際の
意味を持たず、このディレクトリが継承する範囲内で作成された任意のファイルの
継承された
パーミッションを表す。
SambaはNT用にそれら継承されたパーミッションをまとめ、NT ACLとして返すので、 Sambaによって新しく作成されたこの共有のUNIXパーミッションモードを 受け取れる。
ファイルとディレクトリのパーミッションの変更はダイアログボックス中に表示された パーミッションの変更と同じくらい簡単で、
をクリック すればよい。しかし、ユーザーが認識する必要がある制限があり、また、Samba標準の パーミッションマスクと注意を払わなければならない事も必要なDOS属性のマッピング も相互に影響する。
もしも、nt acl supportパラメーターがfalse
ならば、"アクセスが拒否されました"というメッセージが
出力されて、セキュリティパーミッションを設定することは失敗する。
最初に注意することは、"リモートプロ子ジャーコールは失敗し、実行出来ませんでした" というエラーメッセージが表示される)。これは、ダイアログボックス中に一覧表示されて いる、現在のユーザー/グループ/その他 のパーミッションのみを操作できると言うことで ある。これらはUNIXが実際に持っているパーミッションのみなので、これは実際にちゃん と動く。
ボタンはSamba中のユーザーの一覧を 返さない事である(
もしもパーミッションの三つ組み(ユーザー、グループかその他のどれか)がNTダイアログ
ボックス中でパーミッションのリストから削除されたならば、パーミッションなし
状態になる。もしもサイドパーミッションを表示させると、NTのO
フラグとして、上記で説明したようにパーミッションなしが表示
される。これはパーミッションの三つ組から取り去ったものをファイルかディレクトリに
もういちど戻すためにパーミッションを追加できるようにする。
UNIXはNT ACLの“r”, “w”, と “x”ビットのみを
サポートするため、もしも、削除
のような他のセキュリティ属性が
選択された場合、Sambaサーバー上に適用するときには無視される。
ディレクトリにパーミッションを設定する場合、2番目のパーミッションの組(括弧の組の 二番目)は既定値でディレクトリ中のすべてのファイルに適用される。もしも、これが やりたいことではない場合、NTダイアログボックス中の Replace permissions on existing filesチェックボックスの チェックを、 ボタンを押す前に外さなければならない。
もしもすべてのパーミッションを、ユーザー/グループ/その他から取り去りたい場合、
コンポーネントをハイライトさせ、所有権の取得
パーミッション(O
として表示される)のみををハイライトさせてもよい。
標準的なSambaのcreate mask
パラメーターとの相互作用を制御する4つのパラメーターがある:
ユーザーがパーミッションを適用するためにsecurity maskパラメーター中で設定された ビットに対し、ファイルに対して変更されたパーミッションを検査する。このパラメーター 中で1に設定されていない変更されたすべてのビットは、ファイル パーミッション中でそのまま残る。
をクリックした 時、Sambaは与えられたパーミッションを、ユーザー/グループ/その他のr/w/x三つ組 にマップし、次に本質的に、security mask中のゼロビットは、ユーザーが 変更を許可しないビットの組として、1のビットは変更を認めるビットとして扱っても よい。
もしも明示的に設定されていない場合、このパラメーターは既定値として create maskパラメーターと同じ値になる。ユーザーにファイル 上のすべてのユーザー/グループ/その他 のパーミッションの設定変更を許可したいならば、 この値を0777にする。
次にSambaは、force security modeパラメート中で設定された ビットに対して、ファイルのパーミッションの変更点をチェックする。このパラメーター 中で1に設定されたものに対応する、変更された任意のビットは、 強制的にセットされる。
基本的に、force security mode
パラメーター中でビットを設定
することは、ファイル上のセキュリティを変更する時、ユーザーが常時on
に設定するとして、ビットのまとまりを扱っても良い。
もしも、明示的に設定されない場合、このパラメーターの既定値は、
force create modeパラメーターでの値と同じになる。
何の制限もなしにすべてのユーザー/グループ/その他のパーミッションの変更を許可したい
ならば、このパラメーターを000に設定する。
security maskとforce security mode
パラメーターはその順で、変更要求のために適用される。
ディレクトリには、security mask
の代わりに
directory security mask
を、
force security mode
の代わりに
force directory security mode
パラメーターを使う点を除いて、
上記で説明したファイルへの操作と同じ動作をSambaは実行する。
directory security maskパラメーターの既定値は、
directory mask
パラメーターと同じ値に設定され、
force directory security mode
パラメーターの既定値は、
force directory modeパラメーターと同じ値に設定される。
この方法で、その制限内で引き続きパーミッションビットをユーザーに変更許可する
間、Samba共有上で管理者が設定出来るパーミッションの制限を実施する。
もしも、ファイルとディレクトリ上でパーミッションビットを変更する
フルコントロール権をユーザーに許可するように、かつ、強制的に特定のビットを
onに設定しない、共有を設定したいならば、
smb.conf
ファイル中の共有固有のセクションに、以下のパラメーターを記述する:
security mask = 0777 |
force security mode = 0 |
directory security mask = 0777 |
force directory security mode = 0 |
Sambaは(“read-only”のような)DOS属性の一部をファイルのUNIX パーミッションにマップする。これは、セキュリティダイアログ経由での パーミッションビットの設定とファイル属性マッピングによって設定されるビットとの の間に競合が生じることがでてくる。
もしも、ファイルが所有者に対して読み込み権がない場合、これは標準ファイル属性 タブダイアログ中で“読み取り専用”として表示される。都合の悪いことに、 このダイアログは、他のタブ中にあるセキュリティ情報を含むものと同じである。
これができる事が意味するものは、もしも所有者がセキュリティダイアログを使って 自分自身に読み込みを許可するためにパーミッションを修正するならば、 標準セキュリティダイアログに戻るために
をクリックし、 次にNTはファイルのパーミッションを読み取りのみに戻す(ダイアログ中では引き続き 表示される属性)。これは、パーミッション設定後、属性ダイアログに戻るために をクリックした後、変更を書き戻さないようにするため、 の代わりに をクリック する事を意味する。Windowsの管理者は簡単なACL制御になれていて、通常UNIXのユーザー/グループ/その他(ugo) のパーミッションは不十分で十分にきめ細かくないと考えている。
競合しているSMBの実装は、Windows ACLをどのように取り扱うかについて異なる。Sambaは Windows ACLを、UNIXのファイルシステム管理の構造で取り扱い、そのため、POSIX ACLの 制限が適用される。そのため、Windows NT/200X ACLの機能が POSIX ACLには欠如している ので、POSIX ACLのセマンティックスと制限は、Windows管理者に課される。
POSIX ACLはUNIX管理者におもしろい難問を提供し、そのため、Windows ACL管理に適用 するために妥協を強いる。POSIX ACLは公式の標準としては適用されていない。という よりは、最終の標準は、draft standard 1003.1e revision 17である。これが、Samba が実装しているPOSIX文書である。
UNIXベンダは別々の流儀でPOSIX ACLを実装している。ACLをサポートしている数多くの Linuxファイルシステムがある。Sambaは数多くのPOSIX ACLの実装間のすべての違いを 透過的にする仕組みを提供する必要がある。SambaにおけるACLサポートのプレッシャー は、UNIXの世界でのACLサポートの標準化への圧力を顕著に増大する。
SambaはUNIXファイルシステムで実装されているPOSIX ACLが予想していない、 継承を実装しているWindows ACLという難問を取り扱う 複雑な事項を扱う必要がある。Sambaは通常のugoとACL機能を上書きすることが出来る masksのサポートを提供する。これは、WindowsのACLが 実装しなければならない方法を更に複雑にする。
POSIX ACLを調べる際に、ファイルとディレクトリ両方に対して操作する方法を 考えておかなければならない。ファイルのACLは以下の意味を持つ:
# file: testfile <-- ファイル名 # owner: jeremy <-- ファイルの所有者 # group: users <-- POSIXグループの所有者 user::rwx <-- ファイルの所有者に対する許可 (user) user:tpot:r-x <-- 追加のユーザーに対する許可 `tpot' group::r-- <-- ファイルグループの所有者に対する許可 (group) group:engrs:r-- <-- 追加のグループに対する許可 `engineers' mask:rwx <-- グループに対して'論理積'を取る時のマスク値 other::--- <-- その他に対する許可 (other)
ディレクトリのACLは以下の意味を持つ:
# file: testdir <-- ディレクトリ名 # owner: jeremy <-- ディレクトリの所有者 # group: jeremy <-- POSIXグループの所有者 user::rwx <-- 所有者に対するディレクトリの許可 (user) group::rwx <-- 周遊するグループに対するディレクトリの許可 (group) mask::rwx <-- グループに対して'論理積'を取る時のマスク値 other:r-x <-- その他に対する許可 (other) default:user::rwx <-- 継承された所有者に対する許可 default:user:tpot:rwx <-- 継承されたあるユーザーに対する許可 `tpot' default:group::r-x <-- 継承されたグループに対する許可 default:mask:rwx <-- 継承された既定値のマスク default:other:--- <-- 継承されたその他に対するパーミッション (other)
Microsoft Windows NT4/200XのACLはPOSIX ACLに当然マップされねばならない。
ファイルパーミッションのマッピングは、
WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法
で示されている。文字#は、Windows管理者がファイルにフルコントロール
フラグをセットする時のみこのフラグがセットされる事を意味する。
Table 16.5. WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法
WindowsのACE | ファイル属性フラグ |
---|---|
フルコントロール | # |
フォルダーのスキャン/ファイルの実行 | x |
フォルダーの一覧/データの読み取り | r |
属性の読み取り | r |
拡張属性の読み取り | r |
ファイルの作成/データの書き込み | w |
フォルダーの作成/データの追加 | w |
属性の書き込み | w |
拡張属性の書き込み | w |
サブフォルダーとファイルの削除 | w |
削除 | # |
アクセス許可の読み取り | all |
アクセス許可の変更 | # |
所有権の取得 | # |
マッピングテーブルを見てわかるように、1対1でマッピングされるものは1つもなく、 そのため、Sambaは、Windowsに、管理者によって意図されるおおよその方向に操作 させる、論理的なマッピングをしなければならない。
一般的に、UNIX POSIXのユーザー/グループ/その他のパーミッションのマッピングは Windows ACLにマップされる。これは、POSIX ACLの作成に優先する。POSIX ACLは ファイルかディレクトリを所有しているユーザーとグループ以外のユーザーとグループの ためのアクセス制御を行うために必要である。
UNIX管理者はUNIX環境下で任意のディレクトリパーミッションを設定出来る。 Windows管理者はファイルの所有者に対して読み取り許可を削除するために、Windows エクスプローラーで行う事が出来ないというように、より制限されている。
ファイル、ディレクトリと共有アクセスの問題はメーリングリスト上での共通の話題である。 以下は最近メーリングリストで話題になった例である。
以下の不満はSambaメーリングリスト上でしばしば聞かれる:
“
ファイルとディレクトリのパーミッションに関していくつかの問題に直面している。
ドメインにadmin user(root)としてログイン出来、ファイルを作成/変更するための
パーミッションを、誰でも持つ必要があるPublicな共有があるが、rootしかファイルを
変更できず、それ以外の人は出来ない。結局常時サーバーの所に行って、
chgrp -R users *
とchown -R nobody *
を実行し、他のユーザーに対してファイルに対して変更が出来るようにしなければならない。
”
この問題を解決できる1つの方法がある:
共有されているディレクトリの最上位に移動する。
好みのpublicなユーザーとグループに所有者を設定する
$
find `directory_name' -type d -exec chown user:group {}\;$
find `directory_name' -type d -exec chmod 2775 {}\;$
find `directory_name' -type f -exec chmod 0775 {}\;$
find `directory_name' -type f -exec chown user:group {}\;
上記はすべてのディレクトリにSGID ビット
を
設定する。これが何をするかはUNIX/Linuxのマニュアルページを読む
こと。これにより、ディレクトリ中に作成されるすべてのファイルと
ディレクトリツリーは現在のユーザーと、ディレクトリ作成時に所有する
グループによって所有される。
ディレクトリが/foodbar
だとする:
$
chown jack:engr /foodbar
これは以下と同じである:
$
chown jack /foodbar
$
chgrp engr /foodbar
以下のようにタイプする:
$
chmod 2775 /foodbar
$
ls -al /foodbar/..
以下が表示される:
drwxrwsr-x 2 jack engr 48 2003-02-04 09:55 foodbar
以下のようにタイプする:
$
su - jill
$
cd /foodbar
$
touch Afile
$
ls -al
Afile
がJillによって作成されて、所有権を持っている
ことを確認し、以下のようにJackが許可されていることを確認する:
and permissions of Jack, as follows:
-rw-r--r-- 1 jill engr 0 2007-01-18 19:41 Afile
もしも、ディレクトリに書き込みパーミッションを持たねばならないユーザーが
グループengrのメンバーでないならば、smb.conf
中の
共有のエントリを以下のようにする:
force group = engr |
admin users中にユーザーがある時、 force userが設定されていたとしても、 Sambaは常時このユーザーに対してファイル操作をrootとして行う。
質問:“Aが所有者のword文書をBがセーブする。 更新したファイルは所有者がBになる。なぜSambaはこのようにするのか? どうやったら修復できる?”
答え:Wordは、Wordの文書を修正/変更した時に以下の 作業を行う:Microsoft Wordは一時的な名前で新しい文書を作成する。Wordは 次に古い文書をクローズしてそれを削除し、新しい文書をオリジナルの文書 の名前に改名する。Sambaが、新しい文書がオリジナルの文書の所有者によって 所有すべきであるということを知るための機構はない。SambaはMicrosoft Word によってファイルが改名されたことを知るすべはない。Sambaが告げることが 出来る限りのことは、作成されるファイルは新しいファイルであり、 アプリケーション(Word)が更新しているものではない、ということである。
パーミッション問題を解決するための回避方法がある。これは、smb.conf
ファイル中からファイルシステムの動作を管理できる方法についての理解と、
同様に、UNIXファイルシステムの動作について理解することを深める。
Word文書を変更するディレクトリにchmod g+s `directory_name'
を設定する。これは、生成されるすべてのファイルはディレクトリを所有している
グループになるようにする。 smb.conf
中の共有定義セクションを以下のように
設定する。
force create mode = 0660 |
force directory mode = 0770 |
これらの2つの設定は、共有中で作成される、すべてのディレクトリとファイルが ディレクトリそれ自身上に設定された所有者とグループによって読み書きができる ようにする。
Table of Contents
多くのネットワーク管理者に問題を発生させる1つの領域はロッキングである。 問題の範囲はインターネット上で検索することですぐにはっきりする。
Sambaは、Microsoft Windows NT4/200xサーバーも提供する、Microsoft Windowsクライアントが 期待するすべてのロッキングのセマンティクスを提供する。
ロッキングという用語は、並外れて広い意味を持ち、この1つの用語の 配下にすべてカテゴライズされる機能の範囲をカバーしている。
Opportunistic lockingはネットワークで結合されたクライアント上で、アプリケーションの 見かけの性能を向上させることが出来る好ましい機能である。しかし、opportunistic locking プロトコルは頑丈ではなく、そのため、極端に単純化した設定か、広範囲の遅くて障害の多い ネットワーク上を超えて起動するときに、問題に遭遇する。この場合、opportunistic locking のOSによる管理か、反復的なエラーは提供することを意図した考えられる性能の利点を相殺する。
Microsoft Windows ネットワーク管理者は、ファイルとレコードのロッキングセマンティックス (動作)はSamba中かMicrosoft Windowsクライアント上のレジストリの設定で制御できることを 知っておく必要がある。
SMBサーバーによって実行されることが必要な2つのタイプのロッキングがある。最初のものは オープンしているファイル中の一定の範囲のバイト範囲をクライアントがロックすることが できるレコードロッキングである。2番目のものは、ファイルが オープンしているときに指定される拒否モードである。
UNIX配下のレコードロッキングのセマンティックスは、Windows配下のレコードロッキングと大幅に 異なる。Samba2.2より前のSambaは、異なったSambaクライアントとの間で、適切なレコード ロッキングを実装するために、ネイティブなfcntl()UNIXシステムコールを使うことを試みた。 これはいくつかの理由で完全に正しいものにはならなかった。最も簡単なものは、Windows クライアントはロックするバイトレンジとして、クライアントのOSに依存するが、2の32乗か2の 64乗の範囲を指定できた。UNIXロッキングはレンジの幅として2の31乗までしかサポートして いなかった。そのため、2の31乗以上のロック要求を正確に満足させることは出来なかった。 そのほかにもここに記述するのには余りにも多すぎる数多くの違いがあった。
Samba2.2以降では、UNIXシステムに依存しない、独立したレコードロッキングを完璧に実装した。 もしもクライアントが0から2の31乗までの間でバイト幅ロックを要求した場合、SambaはUNIX システムにこの要求を落として扱う。他のどのようなロックもUNIXでは扱わない。
厳密に言うと、Sambaサーバーはファイル上への各読み/書きの呼び出し前にロックのチェックを
すべきである。不幸にも、fcntl()が機能する方法で、これは遅延を引き起こし、
rpc.lockd
に負荷を掛けることになる。これは、それに対してロッキングが
重要なとき、読み書きの前にロッキングを呼び出すことをクライアントは独立して行うはずという
理由で、ほとんど常時不必要である。既定値では、Sambaはクライアントによって明示的に
問い合わせがあったときにのみロッキングコールを行うが、もしも
strict locking = yesを設定した場合、
読み/書きの呼び出し毎にロックチェックの呼び出しを行う。
locking = noを使うことによってバイト幅ロッキングを 完全に停止することも出来る。これは、ロッキングをサポートしない共有か、必要がないとき (たとえばCD-ROMなど)に便利である。この場合、Sambaは毎回OKであると、ロッキング呼び出しの 戻り値をクライアントに返すようにごまかす。
2番目のクラスのロッキングは、deny modesである。これらは、その
オープンに対して同時に許されるべきアクセスのタイプを決めるため、ファイルをオープン
したときにアプリケーションによって設定される。クライアントは、
DENY_NONE
, DENY_READ
,
DENY_WRITE
, か DENY_ALL
を問い合わせできる。
DENY_FCB
と DENY_DOS
と呼ばれる特別な互換
モードもある。
Opportunistic locking (oplocks)はサーバー上に存在するファイルにアクセスする時に、 ネットワークの効率を増大させる目的で、レジストリエントリ(サーバーとクライアント上) 経由でWindowsファイルシステム(APIと対照した場合)によって起動される。効率は、 以下を許容することでクライアント上にローカルにファイルをキャッシュすることにより 増大させる:
oplocksによる効率の増大は、他のプロセスからの同時アクセスのためのファイルのステータスを Windowsがモニターするために、deny-noneでオープンされていたとしても、ファイルに対する 排他的なアクセスを行うことによる。
Windowsは4つの種類のOplocksを定義する:
リダイレクタは、ファイルがdeny none(同時アクセスを許可)で オープンしていることを確認し、ファイルに他のプロセスからの アクセスが無いことを検査し、oplocksが有効になっていることを 確認し、次に、ファイルに対するdeny-all/read-write/exclusive アクセスを許可する。その後、クライアントはキャッシュされたローカル ファイルに対して操作を実行する。
もしも2番目のプロセスがファイルをオープンしようとすると、 オリジナルのoplockをリダイレクタが"ブレーク"するまで オープンは待たされる。oplockブレークは、キャッシュしている クライアントに、サーバーにローカルファイルを書き戻し、ローカルの ロックをフラッシュし、先読みしたデータを廃棄するように通知する。 ブレークが完了し、遅延したオープンが許可され、多重プロセスが、 強制的かバイト幅ロッキングオプションによって指示されたように、 同時ファイルアクセスが出来るようになる。しかし、もしもオリジナルの ファイルがdeny-mode以外の共有モードの場合、次に、2番目の プロセスは、oplockがブレークしても、アクセスが制限されるか アクセスが拒否される。
キャッシングを除いて、Level1 oplockのような機能は、すべての読み出しに 対してのみ重要である。すべてのその他の操作は、サーバー上でファイルの ディスクへのコピーを実行する。
oplocksはファイルシステムによって起動され、アプリケーションAPIではないということは重要な 詳細事項である。そのため、あるアプリケーションはoplockされたファイルをクローズできるが、 ファイルシステムはoplocksを放棄しない。oplockのブレークが発生したとき、ファイルシステムは 次に、2番目のプロセスによる、次のファイルオープンの準備中で、単純にファイルをクローズする。
Opportunistic lockingは、この機能に対して、実際には妥当ではない名前 である。この機能の真の利点は、クライアントサイドのデータキャッシングであり、oplocksは ネットワーク上のディスクストレージにデータを書き戻すための、単なる通知メカニズムである。 oplocksの制限は、サーバーとキャッシュしているクライアント間でのoplocksブレーク(通知)を 処理するためのメカニズムの信頼性である。もしもこの交換に失敗すると(通常、数多くの理由で タイムアウトするという場合)、クライアントサイドキャッシングの優位性は否定される。
ユーザーか管理者が考慮すべき、実際の決断点は、ローカルにクライアント上にキャッシュされる 複数のユーザーのデータ間で共有するのは賢明であるかどうかと言うことである。多くの場合、 答えは「否」である。データをキャッシュするかしないかの決断は真の質問であり、そのため、 oplocksはクライアントサイドのキャッシングのトグルとして取り扱うべきである。クライアント サイドのキャッシングが望ましく、信頼性がある場合、それを“on”にする。 クライアントサイドのキャッシングが不必要で、信頼性に欠け、あるいは反生産的な場合、 “off”にする。
Oplocksは既定値ではすべての設定された共有上にSambaによって“on”に設定されて いるので、もしも潜在的な利便性が、遅延の可能性より小さい場合、それぞれのケースで決定 するときには注意深く行うべきである。以下の推奨項目は、oplocksが効果的になる環境を特徴 づけるのに役に立つだろう。
Windowsのoplocksは簡易な効率向上機能である。これは堅牢でも信頼できるプロトコルではない。 oplocksのすべての実装は、考え得る性能と信頼性との間でのトレードオフとして評価される べきである。信頼性は、上記での継続したルールが適用されないように減少する。oplockが 有効で、WAN上をまたいで、南太平洋の環礁の、高信頼性のサーバー上で、ミッション クリティカルな、多人数で使う会社のデータベースが台風にさらされている状況を考えてみよう。 この設定はoplockの問題に遭遇するだろう。
Oplocksは、クライアントサイドでのデータキャッシングのための構成要素のトグルとして 扱われる時、クライアントの性能を理解するために有益であり得る。もしもデータのキャッシングが さえぎられそうな場合、oplocksの使用は評価されるべきである。Sambaはすべての共有に対して oplocksを既定値で有効にする。サーバー上の共有データ、サーバーネットワークの信頼性と各共有の oplocksの設定の使用法をクライアントに提供すべきであることに注意深く注意を払う。 ミッションクリティカルな領域、高信頼性環境では、データの整合性はしばしば優先度が高く なる。複雑で高価な構成は、もしもクライアントがファイルサーバーへの接続が切れた時、 継続したデータの可用性を提供するために、フェイルオーバーによるサーバー切り替えがすぐに出来る ことが出来るように、実装される。
Windowsクライアントのフェイルオーバーの動作は、確立しているTCP/IPトランスポートコネクション に依存するという理由で、他のプラットフォームよりもアプリケーションの中断のリスクがより 大きい。もしも、ファイルサーバーのフェールオーバーとして接続が中断されたならば、新しい セッションは再度確立せねばならない。トランスポート層が切断された時から正しく復帰するために プログラミングされているWindowsクライアントはまれである。そのため、ほとんどの アプリケーションは、ある種の中断を経験することになる。最悪の場合、アボートして再起動が 必要となる。
もしもクライアントセッションが、oplocksのために、ローカルに書き込みと読み取りを キャッシングしているなら、TCPの中断からアプリケーションの再起動または復帰のときに データが喪失するだろう。ファイルサーバーが復旧すると、oplocksのブレークはクライアント には送信されない。この場合、先のセッションからの作業は失われる。oplocksが無効に なっていて、リアルタイムにファイルサーバーにクライアントがデータを書き込むという シナリオを観察することで、フェイルオーバーは、切断時に存在するディスク上のデータを 提供する。
ミッションクリティカルな、高可用性環境では、oplocksに対して厳重な注意をはらうべきである。 理想的には、広範囲なテストは、oplocksが有効かつ無効な状態で、すべての影響される アプリケーションで行うべきである。
oplocksは、単一のユーザーか、同時に1人のみのユーザーで、排他的にアクセスされる共有に限定 される時に最も有効である。oplocksの本当の姿は、ローカルにクライアントでキャッシング されているデータという理由により、キャッシングを中断する何らかの操作は遅延を引き起こす。
ホームディレクトリは、oplocksが問題ないと理解され、効率を得られる、最も明らかな例である。
共有中のファイルへ各追加ユーザーがoplocksを有効にしてアクセスすると、遅延の可能性と、 結果として生じる性能の低下が増大する。複数のユーザーが、oplocksを有効にした共有上の ファイルにアクセスする時、oplocksブレークの送受信と、の管理と、データのオフセットを フラッシュするためにクライアントのキャッシングを他のクライアントが待つ間に結果として 生じる遅延の管理の影響は、キャッシュしているユーザーの効率向上を相殺する。
oplocksを設定して各追加のクライアントがファイルにアクセスする時、潜在的な効率の 向上は否定され、最終的には効率のボトルネックとなる。
ローカルのUNIXとNFSクライアントは強制的なファイルロックメカニズムなしでファイルにアクセス する。そのため、それらクライアントプラットフォームは、ファイルをキャッシュしている Windowsクライアントにサーバーからのoplocksブレークを初期化できない。ローカルのUNIXか NFSファイルアクセスはこのため、データが壊れるようなファイルを公開している、Windows クライアントによってキャッシュされたファイルに書き込める。
もしも、ファイルがWindows間とローカルUNIXかNFSユーザーによって共有されているならば、 oplocksはoffにする。
クライアントサイドの読み取りと書き込みのキャッシングが、回線上でそれらの読み書きを送る 上での大部分の差分を送る時に、oplocksが遭遇する性能向上の最も大きな可能性がある。 これは、ネットワークがとても遅く、詰まっているか分散している(WAN中の場合)には、頻繁に起きる。 しかし、ネットワークの遅延がoplocksメカニズムの信頼性に関して大きな影響があり、そのため、 潜在的に知覚できる効率の向上を十二分に相殺するoplocks問題を発生する見込みを増大する。 もちろん、もしもoplocksブレークが、決して送られる必要がなければ、これは、oplocksを利用 する最も効率的なシナリオである。
もしもネットワークが遅いか、信頼性がないばあいか、WANの場合、もしも複数のユーザーが 同じファイルを定期的に開く事がある場合、決してoplocksを設定しないこと。
マルチユーザーデータベースは、その本質的な性質から、明らかに危険である。それらは通常不定 間隔でたくさんのユーザーによって激しくアクセスされる。oplocksが有効になっている共有上で マルチユーザーデータベースを配置すると、Sambaサーバー上でのロッキング管理のボトルネックに なるだろう。手作りあるいは所用製品のデータベースアプリケーションのどちらにせよ、 共有のoplocksは無効にすること。
IMAN、EnoviaやCleacaseのようなProcess data management (PDM)アプリケーションはWindows クライアントプラットフォームでの使用が増え、そのため、SMBによるデータ格納も増えている。 PDMアプリケーションは、重要なデータのセキュリティとアクセスのために、複数ユーザー環境を 管理する。一般的なPDM環境では、必要に応じてローカルにロードするデータは、洗練された クライアントデザインのアプリケーションに関連づけられる。更に追加で、PDMアプリケーションは 通常各クライアントのデータ状態をモニターする。この場合、クライアントサイドのデータ キャッシングは、ローカルのアプリケーションとPDMサーバーで協調して保守するために、最も 残される。任意のキャッシング作業からクライアントOSを、任意のoplocks管理から、共有上で oplocksを無効にすることによって取り除くことは適切である。
Sambaには、smb.conf
の変数によって定義されるどんなユーザーにも、接続してきたユーザーが
共有にアクセスする時に、ユーザーを変更するforce userという
パラメーターをsmb.conf
中に含むことが出来る。もしもoplocksが共有上で有効になっている場合、
ユーザーアクセス中の変更は、ユーザーが明示的にファイルをロードしなくとも、クライアントに送信
するoplocksブレークを発生させる。ネットワークが遅いか信頼性がない場合、ファイルにアクセス
しているユーザーなしでoplocksブレークが失われることがある。これは、oplocksブレークの喪失を
補うために、絶えず再接続するクライアントとして見た目の効率低下を引き起こす。
以下を組み合わせることを防ぐ:
smb.conf
中の共有定義中のforce user 。
遅いか信頼性のないネットワーク。
Oplocksが有効。
Sambaはタイミングと使用レベルの計測のためにoplocksメカニズムの、種々のプロパティを 管理者が調整できるoplocksパラメーターを提供する。これらのパラメーターは、問題を引き起こす ような環境中でoplocksを実装するために、すぐれた融通性を提供する。パラメーターは、 oplock break wait timeと oplock contention limitである。
ほとんどのユーザー、管理者と環境にとって、もしも、これらのパラメーターが必要ならば、より良い 選択肢は、単にoplocksをoffにすることである。Samba SWATでは、両パラメーターについて、 “Samba oplocksコードを読解しない限り、このパラメーターを変更しないこと。” という説明がある。これは良い助言である。
ミッションクリティカル、高信頼性を必要とする環境では、データの整合性がしばしば 優先される。複雑で高価な構成は、もしもクライアントとファイルサーバーへの接続が切れた時、 フェイルオーバーによる切り替えが、継続したデータの有効性を提供するためにすぐに行われる ように実装される。
Windowsクライアントのフェイルオーバーの動作は、確立したTCPトランスポート層の接続に 依存しているために、他のプラットフォームよりアプリケーションの中断というリスクとなる。 もしも、ファイルサーバーのフェイルオーバーで接続が中断されたならば、新しいセッションは 確立されねばならない。トランスポート層の切断から正しく復帰するためにコードが書かれている Windowsアプリケーションはまれである。そのため、ほとんどのアプリケーションは、ある種の 中断が生じることになる。最悪の場合、アボートして再起動が必要となる。
もしもクライアントセッションが、oplocksにより、ローカルに読み書きをキャッシュしている ならば、TCPの中断からアプリケーションが再起動か復帰する時、データが失われるかもしれない。 TCPの接続が失われた時、oplocksブレークはクライアントには送られない。この場合、以前の セッションからの作業は失われる。oplocksを無効にしてこのシナリオを観察すると、 もしもクライアントがリアルタイムにファイルサーバーにデータを書き込んでいたら、 フェイルオーバーはディスコネクト時に存在したディスク上のデータを提供するだろう。
ミッションクリティカル、高可用性を要求する環境では、oplocksの使用については厳重に注意を 払う必要がある。理想的には、oplocksを有効/無効にした、すべての影響があるアプリケーション について、広範囲なテストを行うべきである。
oplocsは、ユニークなWindowsファイルロッキング機能である。これは真のファイルロッキング機能 ではないが、Windowsのファイルロッキングの多くの議論中に含まれ、そのため、事実上の ロッキング機能として考えられる。oplocksは、実際の所、Windowsクライアントファイル キャッシング機能の一部である。これは、エンタープライズコンピューティング領域中に存在 する、種々のカスタマイズされたネットワーク上で実装される時には、とりわけ丈夫か信頼性が ある機能ではない。
SambaではWindowsと同様に、クライアント側のキャッシング機構であるoplockを、サーバー側の コンポーネントとして実装している。Windowsの機能設計上、oplock は軽量型として設定されて いる(機能が限定されている)。このためoplockを効果的に設定するには、これらの制限事項の 把握が不可欠であり、またカスタマイズされたネットワークやクライアントの利用状況に特化 したデータアクセスを構成する際の理解が行き届いている場合にのみ適用されるものである。
Oplocksの基本的な意味は、クライアントが、変更中にそのハードドライブ上にファイルを ダウンロードし、キャッシュ出来るということである。もしも、2番目のクライアントがファイルに アクセスしようとした場合、最初のクライアントはブレークを受け取り、サーバーに対して 同期を取らねばならない。これは、ある場合においては、かなり効率が向上する。いくつかの プログラムは、単一の変更のためにサーバーに対してファイルの内容すべてを戻して同期を取る ことを行うものもある。
Level1 Oplocks(単に“oplocks”としても知られている)はopportunistic lockingの 別の言い方である。
Level2 Oplocksはリードオンリとして取り扱うファイルに対して opportunistic lockingを提供する。通常これはリードオンリか、クライアントが、ファイルの オープン時に、最初に書き込まないファイルに使われる。
Kernel OplocksはLinux kernelに、Microsoft Windowsネットワークファイルロッキングのより良い 統合を提供するにも関わらず、Sambaがoplocksしたファイルとの共存を許可する基本的な方式 である。SGI IRIXとLinuxは現時点でoplocksを認識するただ2つのOSである。
使用しているシステムがkernel oplocksをサポートしている限り、UNIX/LinuxとSMBクライアントの 両方から同じファイルをアクセスする時、oplocksを無効にすべきである。もしも、複数の クライアントからデータベースファイルを共有している時(たとえば、Microsoft Access)、 顕著なパフォーマンスダウンと、さらに、最初の場所におけるデータベースのアクセス問題が 発生する、ファイル全体(1つのレコードではなく)の同期に影響する、最初のクライアントが 受け取る任意のブレークという理由で、oplocksは気にせず常時無効にすべきである。 特に、Microsoft Outlookのパーソナルフォルダー(*.pst)はoplocksに対してとてもひどく反応する。 疑っているのならば、oplocksを無効にして、その辞典からシステムを調整してみると良いだろう。
もしもクライアントサイドのキャッシングが無効で、ネットワークの信頼性があるのであれば、 oplocksをonにすることで利点が得られる。もしも、使用しているネットワークが遅くて、信頼性が ないか、他のファイル共有方式(たとえばNFS)との間でファイルを共有しているか、WAN経由の 場合か、頻繁に同一ファイルを複数の人がアクセスする場合、クライアントがoplocksブレークを 送るオーバーヘッドからの利益を得られず、そのかわりに共有に対してoplocksを無効にしたいと 思うだろう。
考慮すべき他の要素は、ファイルアクセスの認識されたパフォーマンスである。もしもoplocks が使用するネットワーク上で、わかるほどのスピード向上を提供しない場合、それを取り扱う 難しさ分の価値がないかもしれない。
以下の節では、Sambaロッキングの制御に関する2つの異なった側面について評価する。
以下のようにして、共有単位でoplocksを無効にすることが出来る:
[acctdata] |
oplocks = False |
level2 oplocks = False |
既定値のoplocksタイプはLevel1である。Level2 oplocksはsmb.conf
ファイル中で、共有単位に
有効に出来る。
代わりに、以下のようにして、共有内でファイル単位にoplocksを無効に出来る:
veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/ |
もしも、Sambaのログエントリから確認出来る、oplocksの問題に遭遇した場合、 安全を期すために、oplocksとLevel2 oplocksを無効にしても良い。
Kernel oplocks は、キャッシュされているファイルをUNIXプロセスがオープンしようとする
時に、(もしもUNIX kernelがWindowsクライアントに対してoplocksを送信する機能がある時)
Sambaに対して通知するsmb.conf
パラメーターである。このパラメーターはUNIXと、Sambaサーバー
上でoplocksが有効になっているWindows間で共有するファイルをアドレスする。UNIXプロセスは
Windowsクライアントによってoplockedされた(キャッシュされた)ファイルを開くことが出来、
ファイルがデータ破壊のリスクがあるという事を伝える、oplocksブレークをsmbdプロセスは
送らない。もしもUNIX kernelがoplockブレークを送る機能があるならば、kenel oplocks
パラメーターは、Sambaにoplockブレークを送ることを有効にする。kernel oplocksは、
smb.conf
ファイル中でサーバー単位に有効に出来る。
kernel oplocks = yes |
既定値はnoである。
Veto oplocksは、oplocksが無効になる特定のファイルを識別するための、
smb.conf
パラメーターである。veto oplocksに設定されているファイルをWindowsクライアントが
オープンする時、クライアントはoplocksが許可されず、すべての操作はクライアント上に
キャッシュされたファイルのコピーの代わりにディスク上のオリジナルのファイル上で実行
される。UNIXプロセスとoplocksを無効にしたそれらファイルとの間で共有されるファイルを
明示的に識別することで、サーバー全体でのoplocks設定が、データ破壊のリスクがない、ファイルの
キャッシングという効率の向上を、Windowsクライアントが利用できることを有効にできる。
veto oplocksは、以下の“いくつかのファイルがoplocksされた共有”で示されるような、smb.conf
中で、
共有単位か、サーバー全体で有効に出来る。
oplock break wait timeは、smb.conf
中のパラメーターで、oplock
ブレーク要求をSambaが繰り返す時間感覚を調整する。Sambaは
“Sambaのoplocksコードを読んで理解しない限りこのパラメーターを変更しないこと”
と忠告している。oplock break wait timeは、以下のように、smb.conf
中でグローバルな形で
のみ設定できる。
oplock break wait time = 0 (default) |
Oplock break contention limitは、smb.conf
中のパラメーターで、
パラメーターによって指定された制限に、設定された数多くの競合するクライアントが到達する
場合、 oplockを許可するためのSambaサーバーのレスポンスを制限する。Sambaは
“Sambaのoplocksコードを読んで理解しない限りこのパラメーターを変更しないこと”
と忠告している。oplock break contention limitは、“Oplock Break Contention Limitの設定”のように、
smb.conf
中で共有単位あるいはグローバルにサーバー全体で有効に出来る。
ネットワーク経由で共有データベースにアクセスする任意のアプリケーションに影響しうる Windows 2000/XPワークステーション上でアプリケーション(Norton Antivirusのような)を 動かす時によく知られている問題がある。これは、Windows 2000/XP OSの既定値の設定の結果に よるものである。他の 2000/XPコンピュータ上の共有データベースファイルに、 ワークステーションがアクセスする時、Windows 2000/XP OSは、ファイルをロックし、情報を ローカルにキャッシュすることで効率を向上することを試みる。これが起きると、 アプリケーションは、ネットワーク操作中、“アクセスが拒否されました”という エラーが表示されて適切に動作しなくなる。
データファイル(データファイルがそこに格納されて、他のWindows PCによってアクセスされる という意味で)のためのデータベースサーバーとして振る舞う、NTファミリの、すべての Windows OSは、データファイルの破損を防ぐリスクを最小限にするために、oplocksを無効にする 必要があるかもしれない。これには、Windows 9x/Me、Windows NT、Windows 200xと Windows XPが含まれる。 [5]
もしも、サーバーの代わりにWindows NTファミリのワークステーションを使っているならば、 そのワークステーション上でoplocksを無効にしなければならない。例えば、もしも、 Windows NT サーバーの代わりにWindows NT ワークステーションをPC上で使っていて、 その上に、他のWindows PCからアクセスされるデータファイルがあるならば、そのシステム上で oplocksを無効にしなければならないかもしれない。
大きな違いは、oplocksを無効にするための値を入れるWindowsレジストリの位置である。 LanManServerの位置の代わりにLanManWorkstationの位置が使われる。
Windowsレジストリエディターを使ってこのレジストリの値を検査(必要に応じて変更か追加)する ことができる。このレジストリ値を変更する時、新しい設定を反映させるために、PCを再起動 しなければならない。
oplocksのためのクライアントレジストリエントリの位置は、Microsoft Windows NTよりも 前の位置から、Windows 2000では変わっている。
Windows 2000 は、以前のWindows中でoplocksを無効にするために使うEnableOplocksレジストリ エントリを引き続き使用している。
以下のレジストリエントリを変更することによって、oplocksの許可を拒否することも出来る:
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\MRXSmb\Parameters\ OplocksDisabled REG_DWORD 0 又は 1 既定値: 0 (無効になっていない)
OplocksDisabledというレジストリエントリ値は、リモートファイル上のoplocksの要求のあるなしを Windowsクライアント上で設定する。oplocksを無効にするためには、OplocksDisabledの値は 1に設定しなければならない。
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 又は 1 既定値: 1 (既定値で有効) EnableOpLockForceClose REG_DWORD 0 又は 1 既定値: 0 (既定値で無効)
EnableOplocksという値はWindowsベースのサーバー(ファイルを共有しているワークステーションを 含む)で、ローカルファイル上のoplocksを許可/拒否することを設定する。
クローズまたはプログラム終了時でオープンしているoplocksを強制的に終了するためには、 EnableOpLockForceCloseを1に設定しなければならない。
Level2 oplocksの動作概要は以下の通り:
ステーション1がoplockを要求してファイルを開く。
他のどのステーションもファイルを開かない間、サーバーはステーション1に排他的oplockを許可する。
ステーション2がoplockを要求してファイルを開く。
ステーション1がまだファイルを書き込んでいないなら、サーバーはステーション1にレベル2の oplockのブレーク通知を行う。
ステーション1はローカルにバッファーした情報をサーバーに書き戻す。
ステーション1はレベル2のoplockを素unしたサーバーに情報を送る(代わりにステーション1は ファイルをクローズすることが出来たはずである)。
サーバーはステーション2のオープン要求に対応し、レベル2のoplockを許可する。 その他のステーションは同じくファイルを開くことが出来、同様にレベル2のoplockが 許可される。
ステーション2(か、ファイルをオープンしている他のステーション)はSMB書き込み要求を 送る。サーバーは書き込み応答を返す。
サーバーは、ファイルをオープンしているすべてのステーションに対して、ロックを 壊さないこと、すなわちファイルに対して oplock を保持しているステーションが ないことを確認する。この時点で、ワークステーションはキャッシュされた 書き込みもロックも保持していないため、break-to-none 勧告に対して応答する 必要がないからである。それぞれのワークステーションは、単にローカルで キャッシュしている先読みデータを無効にするだけでよい。
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanWorkstation\Parameters UseOpportunisticLocking REG_DWORD 0 又は 1 既定値: 1 (真)
これは、リダイレクタがoplockの効率向上機能を使うかどうかを指示する。 このパラメーターは問題を判別するためにのみ無効にすべきである。
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 又は 1 既定値: 1 (真)
これは、サーバーが、ファイルにoplocksを使うことをクライアントに対して許可するか どうかを指定する。oplocksは明確に効率を向上させるが、特にWANのような、ある種の ネットワーク上でキャッシュされたデータを失う可能性がある。
MinLinkThroughput REG_DWORD 0 は秒あたり無限のバイト量 既定値: 0
これは、この接続のための、生の(raw) I/Oとoplocksを無効にする前に、サーバーによって 許可される最小のリンクスループットを指定する。
MaxLinkDelay REG_DWORD 0 から 10万秒 既定値: 60
これは、リンクのディレイで許される最小限の時間を指定する。もしもこの値よりも遅延が 大きい場合、サーバーは生の(raw)I/Oとoplocksを、この接続では無効にする。
OplockBreakWait REG_DWORD 10 から 180 秒 既定値: 35
これは、oplockブレーク要求に対してクライアントが返答するまで、サーバーが待つ時間を指定 する。より小さな値はより速やかにクラッシュしたクライアントを検出できるが、キャッシュした データを失う可能性がある。
もしもこの章で議論されている設定のすべてを適用したが、データの破壊問題と他の症状が持続 しているのであれば、追加して監視するものがある。
単独の欠陥があるネットワークカードのような、欠陥があるネットワークハードウェアについて、 開発者から信用できる報告を受けていることが、読み取りキャッシングとデータ破壊に類似して いる兆候を引き起こす。もしも、繰り返しインデックスした後にもかかわらす、持続的なデータ 破壊が起きているならば、問い合わせ中でデータファイルの再構築をしなければならないかも しれない。これは、リビルドするようなのと同じいくつかの定義で新しいデータファイルを作成 することを改善し、古いファイルから新しいファイルにデータを転送する。Samba知識ベース中で 見つけることが出来る、これを行う、いくつかの手法がある。
サーバーをインストールするやいなや、問題が表面化するサイトがある。他のサイト内では長い 間問題が表面化していない。例外を除いてほとんど、問題が表面化したとき、当惑と、潜在的な データ破壊を引き起こすだろう。
過去数年の間、Sambaがデータ破壊を引き起こすというクレームの、数多くの不満が、Samba メーリングリスト上に投稿されてきた。3つの原因が認識されてきた:
不正なoplocksの設定(アプリが使うものとの非互換)。これは、Microsoft Windows NT4か Microsoft Windows 200xベースで使っているサーバーでも共通の問題である。ソフトウェア アプリケーションベンダのファイルロッキングに関する設定手順に急いで従うべきである。 もしも疑うのであれば、サーバーとクライアント両方でoplocksを無効にする。Microsoft Windowsクライアント上でキャッシングするすべての形式のファイルを無効にすることも 必要かもしれない。
不完全なネットワークカード、ケーブル、あるいはハブ/スイッチ。これは、一般的に 低コストネットワークハードウェアにおける一般的な事項であるが、より高級なハード ウェアにおける非互換性の問題も時折ある。
データファイルを書く時にSambaのログファイルに時折痕跡が残ることがある。これは、 ごく少数のサイトで報告されていて(過去3年でおおよそ5つ)、すべての再現試験は 失敗した。Sambaチームはこの現象を捕まえられず、そのため、何らかの特定の現象と して分離できていない。Sambaを使う非常に数多くのシステムがあることを考えると、 Sambaチームと同様に、これに影響を受けたサイトにとって、これはいらいらする、 やっかいな難問である。もしも、このタイプの現象に遭遇したならば、遅滞なく、 SambaのBugzillaにバグレポートを 投稿してほしい。可能な限りのたくさんの情報をもらえると、現象の特定の手助けと、 (問題の特定と修正のための基本的なステップである)問題の再現の手助けになる。
“ 以下のようなたくさんのエラーメッセージがSambaのログ中にある: ”
tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic 0x4d6f4b61 at offset=36116
“ これは何を意味するのか? ”
このエラーはtdbファイルが壊れていることを表示している。smbdのすべてのプロセスを停止し、 locking.tdbを削除してsmbdを再起動する。
Microsoftのサポートwebサイトで、
ファイルとレコードのロッキングに関する更新された文書をチェックしても良いだろう。
追加で、Sambaのwebサイトで、
locking
という単語を探しても良いだろう。
Microsoft MSDNライブラリ上にある opportunistic locking 節は以下の通り:
Microsoft KB, “OPLOCKS によるトランザクションの整合性を維持”, Microsoft Corporation, April 1999, Microsoft KB の記事 224992(訳注:機械翻訳).
Microsoft KB, “Windows で Opportunistic Lock を構成する”, Microsoft Corporation, April 2001 Microsoft KB の記事 296264.
Microsoft KB, “PC Ext: Windows NT の Opportunistic Locking の説明”, Microsoft Corporation, April 1995 Microsoft KB の記事 129202.
Table of Contents
この章に含まれる情報は、一般的にすべての導入したSambaに対して適用できる。セキュリティは IT界において、すべての人の関心事である。驚くべき数のSambaサーバーが直接インターネットに 接続するマシン環境上にあり、そのため、ファイアウォールの内側でプライベートネットワーク 上にあるサーバーよりもよりセキュリティ的に危険な状態にある。極端にサーバーセキュリティを重視 する場合、セキュアなネットワーク中に配置されるサーバーはもちろん、頑丈なファイアウォールを、 ネットワーク管理者の一部が要求することになる。この章では、どのように必要とされる障壁 (バリア)を作るかと言うことと、“脅威”に対する防御を理解する管理者(所属は 問わない)を手助けする情報を提供する。
新しい実習生が、ボイラー室のチーフエンジニアの所に、任務のために出勤してきた。彼曰く、 “ただいま出勤しました。ボイラーを見せていただければ作業を開始します。” エンジニア曰く、“そのボイラーに腰掛けているぞ!”
セキュリティに関する関心はこのようなものである。その大部分が本当にどのくらい明白かを 評価するため、この問題に対して多少知っておく必要がある。挑戦の大部分は、熟練者が持つ 秘技を解き明かすかもしれない知識の最初のかけらを探り出すことである。
サイトを少なくとも適度に安全にするために守るべき、セキュリティ原則の3つのレベルがある。 それらは外側に対するファイアウォール、Sambaが動いているホストサーバーの設定とSambaそれ 自身である。
Sambaは、ネットワークセキュリティに対する最も柔軟なアプローチを認めている。可能な限り、 Sambaは、Microsoft Windowsのファイルとプリント操作に対して許可される、よりセキュアな、 最も最新のプロトコルを実装している。
Sambaはローカルネットワーク外から来る接続からセキュアに出来る。これは
ホストベースの保護を、“tcpwrappers”として知られている、
技術の実装を使うことか、インタフェースベースの除外を使うことで行え、
その結果、smbdは許可された特定のインタフェースのみにバインドする。また、たとえば
[IPC$]
自動共有上のような、共有またはリソースベースの除外を
設定することも可能である。[IPC$]
共有は、TCP/IPコネクションを
確立するのと同様、ブラウジング目的に使われる。
Sambaをセキュアに出来る他の方法は、共有それ自身に、アクセスコントロールリスト(ACL)中に アクセス制御エントリ(ACE)を設定することである。これは ファイル、ディレクトリと共有のアクセス制御 に説明がある。
既知のセキュリティ上の弱点と侵害技術に対して保護するために、せいぜいドアを閉めることで 十分であることが、セキュリティの鍵となる難問である。これらの少ない処置を行ったので、 Sambaサーバーが入り込めない要塞になると仮定してはいけない。これまでの情報システムの歴史を 見れば、誰かが他の脆弱性を見つけ出すのは時間の問題である。
数多くのインストール済みSambaにおいて、最も大きな脅威は、隣接したネットワークの 外部から来る。既定値で、Sambaは任意のホストからの接続を受け、それはすなわち、 もしも、インターネットに直接接続されているホスト上でセキュアでないバージョンの Sambaを動かしていた場合、特に脆弱になるということである。
この場合の最も簡単な修正の1つは、hosts allowと
hosts denyをSambaのsmb.conf
設定ファイル中で、
特定の範囲のホストから飲みサーバーにアクセスを許可するように使うことである。
設定例は以下の通り:
hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24 |
hosts deny = 0.0.0.0/0 |
上記はSMB接続を、localhost
(自分自身)と2つのプライベート
ネットワークである192.168.2 と 192.168.3. からのみ許可する。その他の接続要求は
クライアントから最初のパケットが来たらすぐに拒否される。拒否は、
呼び出された名前ではリッスンしていない
というエラーとして
マークされる。
もしも、サーバーへのアクセスを有効なユーザーのみに制限したいならば、以下の方法を
使うことが出来る。smb.conf
中の[global]
セクションに
以下を記述する:
valid users = @smbusers, jacko |
既定値では、Sambaはシステム上にある任意のネットワークインタフェースからの 接続を受け付ける。これは、もしもISDNかPPPでインターネットに接続している 場合、Sambaはそれらからの接続を受け付けるということである。これはおそらく 希望していることではないだろう。
この動作は、以下のようなオプションで変更できる:
interfaces = eth* lo |
bind interfaces only = yes |
これは、たとえばeth0
や eth1
のような
eth
で始まる名前のインタフェースと、lo
という名前のループバックインタフェースからの接続のみを受け付ける事を指示する。
必要とする名前はどのOSを使っているかに依存する。上記ではLinux上での共通的な
イーサネットアダプターの名前を使っている。
もしも、上記を使い、誰かがppp0
という名前のPPPインタフェース
上でホストに対してSMB接続を行おうとした時には、TCPの接続が拒否されたという応答が
帰る。この場合、OSが、任意のSambaプロセスに対して、そのインタフェースからの接続を
渡さないと通知するため、Sambaは全く動作しない。しかし、接続拒否という応答は、
クラッカーに対して、そのIPアドレスが有効なサービスを提供しているという確認をさせて
しまうということにもなる。
もっと良い対応は、接続を全く無視することである(たとえばppp0から)。接続を拒否する ことと比較して接続を無視する試みの利点は、脆弱性攻撃かサービス不能(DoS)攻撃時に 後で使うための有効なIPアドレスを見つけるためが唯一の意図の探索を失敗させることで ある。潜在的な悪意がある行動を取り扱うこの方法は、適切なファイアウォール機構 を使うことが必要である。
多くの人が、使用しているネットワーク外に公開したくないサービスへのアクセスを拒否 するためにファイアウォールを使っている。これはよいアイデアではあるが、上記の と関連して使用することを勧める。そうすると、何らかの理由でファイアウォールが 無効になったとしても保護が出来る。
もしもファイアウォールを設定するとき、どのTCPとUDPポートを許可し、ブロック るかを知っておく必要がある。Sambaは以下のポートを使う:
Port 135/TCP - used by smbd |
Port 137/UDP - used by nmbd |
Port 138/UDP - used by nmbd |
Port 139/TCP - used by smbd |
Port 445/TCP - used by smbd |
最後のものは、多くの古いファイアウォールの設定がそれを知らないかもしれない という理由で重要である。このポートは最近付け加えられた。
ファイアウォールを設定するとき、ハイオーダポート(1024-65535)は外向きの接続に 使われ、そのため、ファイアウォールを通るようにする必要がある。確立した接続を 除いて、ハイオーダポート上の入力パケットをブロックすることは賢明である。
もしも、上記の方法が適していないのであれば、最近セキュリティホールで使われた IPC$共有に拒否の設定をすることが出来る。これは、潜在的に信頼できないホスト からのIPC$へのアクセスを拒否する間、他の共有へのアクセスを提供する。
これを行うには以下のようにする:
[IPC$] |
hosts allow = 192.168.115.0/24 127.0.0.1 |
hosts deny = 0.0.0.0/0 |
これは、2つの指定されたネットワークアドレス(ローカルホストと 192.168.115の サブネット)以外のどこからもIPC$共有への接続を許可しないようにSambaに指示する。 IPC$共有のみが常時匿名でアクセスできる共有であるという理由で、これは、 そのホストで有効なユーザー名/パスワードを知らない攻撃者に対してあるレベルの 保護を提供する。
もしもこの方法を使うのであれば、クライアントがIPC$共有にアクセスした時に、
`access denied'
となる。それらクライアントは共有をブラウズ
出来ず、その他のリソースの一部にもアクセスできないだろう。この方法は、ここで説明
してきた方法のどれかが、何らかの理由で使えない場合を除いて推奨しない。
NTLMv2認証を設定するためには、以下のレジストリキーは知っておく価値がある:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "lmcompatibilitylevel"=dword:00000003
0x00000003という値はNTLMv2レスポンスのみを送ることを意味する。クライアントは NTLMv2認証を使う。もしもサーバーがサポートしているなら、NTLMv2セッション セキュリティを使うこと。ドメインコントローラーはLM、NTLMとNTLMv2認証を受け取る。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0] "NtlmMinClientSec"=dword:00080000
0x00080000という値はNTLMv2セッションセキュリティのみを許可することを意味する。 もしも、NtlmMinClientSecかNtlmMinServerSecが0x00080000に設定されるならば、 もしもNTLMv2セッションセキュリティがネゴシエートされたときに接続は失敗する。
アップデートと重要な通知があるかどうかを、 http://www.samba.org/ で定期的に確認してほしい。時折セキュリティリリースが作成され、セキュリティ上の脆弱性が 発見されたときには直ちにSambaをアップグレードすることを強く推奨する。また、OS固有の アップグレードはOSベンダに確認すること。
もしも、SambaおよびSambaが動作するホストの設定が、誰もが期待するように直感的であれば、 この章は不必要である。セキュリティの問題は、問題の複雑性の理由からではなく、 セキュリティ問題の要求と判明することを投稿するほとんどの管理者が、全くSambaの問題で あると確信しているという理由で、サポート担当の人にとってしばしばやっかいである。
これはよくある問題である。Linuxベンダは既定値のファイアウォールをインストールする 傾向がある。既定値のファイアウォールの状態ではループバックアダプター (IPアドレスが 127.0.0.1)のみの通信が、ファイアウォール経由で許可される。
解決方法は、ファイアウォールを取り除く(停止する)か、SMBネットワークトラフィックが 通過できるようにファイアウォールスクリプトを修正することである。 ファイアウォールの使用の節を参照のこと。
“ 一度有効なパスワードが供給されると、他のユーザーのホームディレクトリへ個別のユーザーが マッピングすることを阻止できない。ユーザーが自分自身のホームディレクトリのみを マッピング出来るように、Sambaを設定する方法を見つけられない。 ”
“ ユーザーxyzzyは自分自身のホームディレクトリをマップ出来る。一度マップすると、ユーザー xyzzyは他の誰のホームディレクトリでもマップ出来る。 ”
これはセキュリティの欠陥ではない。これはデザインによるものである。Sambaは、 定義された共有に許されるように、ファイルシステム上のそのような表示のみを 認める事を除いて、UNIXマシンにログオンしていた時と正確に同じような、 UNIX ファイルシステムへのアクセスをユーザーに認める。
もしも、使用しているUNIXのホームディレクトリが設定されていてあるユーザーが、
他のユーザーのディスク中に、何の問題もなくcd
でき、
ls
を実行出来るならば、UNIXのセキュリティの解は、
ユーザーのホームディレクトリ上のファイルのパーミッションを変更して、
そのために、 cd
と ls
は拒否される。
Samba は、UNIX管理者が定めるセキュリティポリシを勝手に解釈(second guess) しないように、非常に気を使っており、UNIX管理者が、ポリシーやパーミッションを 意図通りに(desire)設定していると確信している。
Sambaは要求した動作を許可する。[homes]
共有定義中に
only user = %Sオプションを単におくこと。
Samba allows the behavior you require. Simply put the only user = %S
option in the [homes]
share definition.
only userパラメーターは users = listパラメーターと一緒に動作するので、 要求する動作を得るためには以下の行を追加する:
users = %S |
これは下記を追加するのと同じである。
valid users = %S |
[homes]
共有の定義のためには、smb.conf
マニュアルページでの推奨のようにする。
Table of Contents
Samba-3はNT4形式のドメイン信頼関係をサポートする。NT4形式のドメインからSamba-3に移行 したいが、Active Directory やLDAPベースの認証バックエンドを採用したくないという多くの サイトが使用したいと思う機能である。この章では、信頼関係に関する背景情報と信頼関係の 作成方法を説明する。Samba-3はNT4を信頼することができ(その逆も可)、またSamba対Sambaの 信頼を作成することも可能である。
ドメイン間の信頼関係を使う場合、winbind
を使うことが必要であるので、
winbindd
が動いていなければならない。このモードにおけるwinbindの
動作は、smb.conf
ファイル中の有効なUIDレンジと有効なGIDレンジの指定に依存する。
これらは以下のように指定する:
idmap uid = 10000-20000 |
idmap gid = 10000-20000 |
指定されたレンジの値はホストOSで使っている値とPOSIXユーザーアカウント用のpassdbバック エンドで使っている値を上書きしてはならない。最大値はホストOSによって許可されている 上限の値で制限される。これはUNIXカーネルで制限されるパラメーターである。Linux kernel 2.6ベースのシステムは最大値として4294967295(符号なし32ビット値)である。
Samba-3はSambaとMicrosoft Windows NT4形式と同じようにSamba間の信頼関係に参加できる。 これは、Microsoft Windows NT4と同様な拡張性をSambaに付与する。
Samaba-3はLDAPのような拡張性のあるバックエンド認証データベースと共に動作でき、プライマリ 及びバックアップドメイン管理モードで動作できるので、管理者はドメイン間の信頼関係を使用 する代わりの選択肢を考慮するべきである。なぜならば、この機能はその動作原理からして、 本質的に脆弱なものだからである。このことこそが、Microsoft Active Directory が開発され 採用される主な理由でもある。
MS Windows NT3/4形式のセキュリティドメインは、階層がないセキュリティ構造を採用している。 この構造の制約が、大規模な組織では Microsoft Windows ネットワークの拡張性に影響を与える ことはよく知られている。さらに、この設計の結果であるフラットな名前空間は、大規模で 多様性に富む組織における管理責務の代行に多大な影響を及ぼす。
Microsoft は、古いテクノロジーの制約を回避するために、Active Directory Service(ADS)を、 Kerberos及びLDAPをベースとして開発した。しかし全ての組織が ADSを採用する準備ができ、 その意思があるわけではない。小規模の組織にとっては古い NT形式のドメインセキュリティで 充分である。また、ADS を採用するために面倒な変更作業を行うことを望まない保守的な ユーザーも残っている。
Microsoft Windows NTで、Microsoft はあるドメインのユーザーが、別のドメインのアクセス権や 他の権限を付与されるような機構を実現するため、多様なセキュリティドメインの存在を可能に する機能を導入した。この機能を信頼(Trusts)という言葉で言い表わす。 具体的には、あるドメインが別のドメインのユーザーを信頼するという ことである。あるドメインのユーザーが別のセキュリティドメインのユーザーになれる時、 そのようなドメインを信頼される(trusted)ドメインと言う。そのようなユーザーに権利や権限を 与えた方のドメインは信頼する(trusting) ドメインと言う。NT3.x/4.0 では信頼関係は一方向 のみである。そのため双方のドメインのユーザーが他方のドメインで権限と権利を持とうとする 場合には、それぞれの方向に一つずつ、二つの信頼関係を設定する必要がある。
NT4形式のMicrosoft セキュリティドメインでは、全ての信頼は非推移的である。この意味は、 例えば三つのドメインがあり(仮に赤、白、青とする)、その赤と白が信頼関係を持ち、また 白と青が信頼関係を持つとする。この場合、赤と青のドメインの間に暗黙に了解された 信頼関係を持つわけではない。関係は明示的でなければならず、推移的ではない。
Microsoft Windows 2000から登場した新たなADSセキュリティの方式では、信頼関係は既定値で 双方向になっている。また、全てのADSドメイン間の信頼は推移的である。上の赤、白、青 ドメインの例では、Windows 2000及びADSを使用する場合、赤と青ドメインは互いに信頼できる。 これはADSドメインの本質的な特長である。Samba-3 はMicrosoft Windows NT4方式のドメイン間 信頼機能を実装し、Microsoft Windows NT4方式のドメインと類似した方法で、 Microsoft Windows 200x ADS セキュリティドメインとの相互運用を実現している。
ドメイン間信頼関係を作成するには二つのステップがある。双方向の信頼関係を有効にする ためには、双方のドメイン管理者が相手のドメインのために信頼アカウントを作成し、 セキュリティに関する信用情報を確認する際に使用できるようにしなければならない。
Microsoft Windows NT4では、全てのドメインの信頼関係は ドメインユーザーマネジャを使って設定する。これは、 メニューバーのドメインユーザーマネジャーポリシーのエントリから行う。 メニューから を選択する。 と記された低い方のボックスの隣に二つの ボタンがある。 と である。 ボタンは、自ドメイン内のユーザーにアクセス権限を付与することが できるリモートドメイン名を入力するパネルを開く。また、信頼するドメインが信頼される ドメインのユーザーを認証するときに使用する、信頼関係のパスワードも入力する必要がある。 パスワードは(標準的な確認の手続きとして)二度入力しなければならない。
信頼関係は、もう一方のドメイン(信頼するドメイン)が信頼されるドメインと適切に接続された 場合のみ動作する。信頼関係を完成するためには、管理者はまず、ドメインユーザーマネジャを 起動し、メニューからポリシーを選択し、 それから信頼関係を選択し、信頼される側のドメイン と記されたボックスの横の ボタンをクリックする。パネルが 開いたらリモートドメイン名とパスワードを入力する。
双方向の信頼関係は、二つの方方向の信頼がそれぞれ互いの方向に作成されることで築かれる。 二つのMicrosoft Windows NT4ドメイン間で片方向の信頼が確立されている場合(仮にDomAとDomB とする)、次の機能が可能になる:
DomA(DomB への信頼接続を完了する)はDomBを信頼する
。
DomAが信頼する
ドメインである。
DomBが信頼される
ドメインである(信頼アカウントの起点)。
DomB のユーザーは DomA のリソースにアクセスすることができる。
DomA のユーザーは DomB のリソースにアクセスすることはできない。
DomB のグローバル・グループは DomA で使用できる。
DomA のグローバル・グループは DomB では使用できない。
DomB は DomA のクライアントワークステーションのログオンダイアログボックスに表示される。
DomA は DomB のクライアントワークステーションのログオンダイアログボックスに表示されない。
信頼するドメインのユーザー/グループは信頼されるドメインへの権限、許可、 アクセスは与えられない。
信頼するドメインは信頼されるドメインにアクセスしたり(ユーザー/グローバルグループの) アカウントを使用することができる。
信頼されるドメインの管理者は信頼するドメイン内で管理権限を付与される。
信頼されるドメインのユーザーは信頼するドメインで権利や特権を付与される。
信頼されるドメインのグローバルグループは信頼するドメインで権利や許可を 与えられる。
信頼されるドメインのグローバルグループはMicrosoft Windowsドメインメンバー マシンのローカルグループのメンバーになることができる。
ここでは、Samba サーバーがドメイン間の信頼関係に参加できるようにするための設定方法を、 簡潔に紹介する。Samba における信頼関係のサポートは初期段階なので、正しく機能しない ことがあっても驚かないこと。
下記における手順の説明では、信頼関係の相手先のドメインは、Windows NT4 サーバーで管理 されていると仮定する。しかし、リモート側は Samba-3 ドメインであっても構わない。 この文書を読み終わるころには明らかになることであるが、以下に書かれている説明のうち、 Samba固有の部分のみを合わせると、純粋なSamba環境におけるドメイン信頼の構築の説明と なる、ということである。
Samba PDC を、信頼関係のある二者のうち信頼される側に設定するためには、まず信頼する側の
ドメインのための特別なアカウントを作成する必要がある。そのためには
smbpasswd
ユーティリティを使う。信頼されるドメインアカウントを
作成するのは、信頼されるマシンアカウントを作成するのに似ている。仮にドメイン名をSAMBA
とし、リモートドメインをRUMBAとする。最初のステップは好みのシェルからこのコマンドを
発行することである:
root#
smbpasswd -a -i rumba
New SMB password:XXXXXXXX
Retype SMB password:XXXXXXXX
Added user rumba$
ここで、-a
はパスワードデータベースの中に新規のアカウントを追加するこ
とを意味し、-i
は、
“このアカウントをドメイン間の信頼フラグ付きで作成せよ”ということを意味する。
このアカウント名は“rumba$”(リモートドメインの名前)である。もしもこの
ステップが失敗した場合、信頼アカウントがシステムのパスワードデータベース
(/etc/passwd
)に追加されたか確認すること。もしも追加されて
いなければ、手動で追加し、上のステップを再度行うこと。
このコマンドを実行後、そのアカウントのパスワードの入力要求が来る。ここでは任意の パスワードを使用できるが、Windows NTではアカウント作成後7日間はパスワードを変更できない ので、注意すること。コマンドの実行が成功すると、新しいアカウントのエントリを、 (設定した環境でのの標準的な方法で)見ることができるので、アカウント名が本当にRUMBA$で、 フラグ欄に“I”が設定されているか確認する。この信頼関係の設定を完成する ために、次は Windows NTサーバーの方から信頼を設定する。
ドメインユーザーマネージャを開き、メニューから
を選び、 を選択する。
信頼されたドメインリストボックスのそばの
ボタンをクリックする。信頼されたドメインの名前とそのパスワードを入力するダイアログ
ボックスが表示される。リモートドメインの名前としてSAMBAを入力し、アカウント作成時に
使用したパスワードを入力する。 をクリックし、すべてが何事も
なくうまくいくならば、
信頼関係が確立しました
(訳注:英文では
Trusted domain relationship successfully established
)が表示される。
ここでは作業の順番が逆になる。今回も、Samba PDCに管理されるドメインを「SAMBA」とし、 NTが管理するドメインを「RUMBA」とする。
一番初めのステップはRUMBAのPDCにSAMBAドメインのアカウントを追加することである。
ドメインユーザーマネージャを起動し、 、 を選択する。次に、 信頼するドメインのボックスのそばの ボタンをクリックし、信頼されるドメイン(SAMBA)の名前を入力し、信頼関係を確立するために 使用するパスワードを入力する。
パスワードは任意に選択できる。Sambaサーバーでは、いつでも容易にパスワードを変更することが できる。パスワードを確定するとアカウントは準備完了である。次は Sambaの番である。
rootでログインし、好みのシェルを使って以下のコマンドを発行する:
root#
net rpc trustdom establish rumba
Windows NT4サーバーで入力したばかりのパスワードが聞かれる。時々、
NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT
というエラーメッセージが
現れるが、問題はないので無視して構わない。これは入力したパスワードが正しく、この
アカウントは通常の接続ではなく、ドメイン間接続のための準備ができている、と NTサーバーが
言っている、という意味である。その後、(大規模ネットワークの場合は特に)しばらく時間が
かかるかもしれないが、我慢する。しばらくするとSuccess
という
メッセージが表示される。おめでとう! これで信頼関係が成立した。
secrets.tdb
ファイルに書き込み権がなければならないので、上記の
コマンドはrootとして実行すること。
ドメインユーザーマネージャが無いにもかかわらず、ミックスモードで 動作するWindows 2000ドメインコントローラーを、信頼するサーバーとして、NT4形式の信頼関係を設定 することは可能である。また、SambaがWindows 2000サーバーを信頼することもできるはずだが、 この領域ではさらにテストが必要である。
前述のように、
Sambaサーバー上でのドメイン間信頼関係の作成
で、信頼関係を作成したら、SambaユーザーにアクセスさせたいリソースのあるドメインのAD
コントローラー上で、Active Directoryドメインと信頼関係
ダイアログボックスを開く。NT4形式の信頼関係は推移的ではないので、自ドメインのユーザーが、
AD内の複数のミックスモードのドメインにアクセスできるようにしたい場合は、各ドメインに
ついて上記の手順を繰り返さなければならない、ということを忘れないこと。
Active Directoryドメインと信頼関係を開き、Samba ドメインを信頼する Active Directory ドメインの名前を右クリックし、 を選択し、
信頼タブをクリックする。パネルの上部に
このドメインによって信頼されるドメイン:という名前の付いた一覧が
表示され、その隣に追加...ボタンがある。このボタンをクリックすると、
NT4のように、信頼されるドメインの名前と関係パスワードを聞かれる。OK
をクリックし、しばらくすると、
Active Directoryから、信頼されるドメインが追加されて信頼関係が確認された
というメッセージが表示される。これで、自システムのSamba ユーザーに、ADドメインの
リソースへのアクセス権限が付与された。
ドメイン間の信頼関係は、不安定な、又は頻繁にダウンするようなネットワークで試みるべきでは ない。ネットワークの安定性と整合性は、分散型ネットワークにおけるドメイン間の信頼関係の ための必須要件である。
信頼されるWindows200xドメインのマシンから信頼するSambaドメインのWindows200x メンバーをブラウズしようとすると、次のエラーが出
システムはセキュリティを侵害しようとするような行為を検出しました。 認証を受けるサーバーに連絡が取れることを確認してください。
接続しようとしているサーバーのイベントログに、下位レベルのドメインのメンバーで あるためにグループポリシーが適用されない、というエントリがある。
問題のマシンのコンピュータアカウントが Windows200xドメインにあり、それが無効化されて いる場合にこの問題が起こり得る。コンピュータアカウントがない(削除されたか、もともと 存在しない)か、そのアカウントを有効になっていない(すなわち、そのアカウントを他の ドメインに参加させただけという)場合は、問題は起こらないようである。既定値では、 ドメイン(Windows 200xドメイン) から離脱する場合、コンピュータは自動的にドメイン内の コンピュータ・アカウントを無効にしようとする。アカウントを無効化する権限をもつ アカウントととして操作していた時にドメインからマシンを離脱した場合、アカウントの 無効化が実行される。そうでなければ実行されない。
ドメイン間の信頼関係を設定するために、信頼アカウントを作成するために、
smbldap-useradd
スクリプトを使うと、信頼関係の設定処理は失敗する。
LDAPデータベース中に作成されたアカウントはアカウントフラグとして
[W ]
となっていて、ドメイン間の信頼関係が動作する時に
必要である[I ]
がない。
これに対する簡単な解決方法がある。 以下のようにして、マシンアカウントを作成する:
root#
smbldap-useradd -w domain_name
次に、信頼アカウントのパスワードを設定する:
root#
smbldap-passwd domain_name\$
テキストエディターを使って以下のファイルを作成する:
dn: uid=domain_name$,ou=People,dc={your-domain},dc={your-top-level-domain} changetype: modify sambaAcctFlags: [I ]
次に、以下のようにして、LDAPデータベースにテキストファイルを適用する:
root#
ldapmodify -x -h localhost \
-D "cn=Manager,dc={your-domain},dc={your-top-level-domain}" \
-W -f /path-to/foobar
NT4のドメインユーザーマネージャから片方向の信頼関係を作成した後、以下を実行する:
root#
net rpc trustdom establish domain_name
この機能は Samba-3とNT4ドメインで動くし、Samba-3とミックスモードの Windows 200x ADSでも 動作する。sambaとNTの両方のDCが同じWINS サーバーを使用していなければならず、 そうでなければ信頼関係は動作しない。
Table of Contents
分散ファイルシステム (DFS) はネットワーク上にある資源について実際の物理的な配置 から、ユーザーが見ているファイルとディレクトリの論理的ビューを切り離す手 段を提供する。 高い可用性と円滑なストレージ拡張、負荷分散などを可能にする。
DFS の情報について、Microsoft documentationを参照のこと。 この文書は、 Samba を利用している UNIX で (DFS対応クライアントがブラウズするため) DFS ツリーを どのようにホスティングするか説明する。
Samba サーバーは、smb.conf
ファイルのグローバル Boolean パラメーター
host msdfsを設定することで DFS サーバーにできる。
共有レベルの論理値パラメーターmsdfs rootによっ
て共有を DFS ルートとして指定できる。
Samba 上の DFS ルートディレクトリはシンボリックリンクの形式で DFS リンクを提供
できる。例えば、共有ディレクトリ内のシンボリックリンク
junction->msdfs:storage1\share1
は DFS ジャン
クション (接点) として機能する。 DFS 対応クライアントがジャンクションリ
ンクにアクセスしようとするとき、それらは実際のストレージ ( この場合
は \\storage1\share1
) にリダイレクトされる。
Samba 上の DFS ツリーは、 Windows 95 から Windows 200x までの DFS 対応クライア
ントをサポートしている。
以下の設定例は、 Samba サーバーでどのよう
に DFS ツリーを設定するかを示す。
ディレクトリ/export/dfsroot
内で、他のネットワーク上のサー
バへの DFS リンクを設定する。
root#
cd /export/dfsroot
root#
chown root /export/dfsroot
root#
chmod 755 /export/dfsroot
root#
ln -s msdfs:storageA\\shareA linka
root#
ln -s msdfs:serverB\\share,serverC\\share linkb
DFS ルートとして使用しているディレクトリのパーミションと所有者の設定を行い、 特定のユーザーだけが msdfs リンクを作成、削除、変更できるように設定すべきであ る。 シンボリックリンク名は、すべて小文字にすべきことに留意すること。この制約は、 Samba が、リンク名を取得するために、すべての大文字、小文字の組み合わせを試 すことを避けるために設けられている。 最後に、ネットワーク上の共有したいところへシンボリックリンクを張り、Sambaを起動する。
これで DFS 対応クライアントは、 \\samba\dfs
にある Samba
サーバー上の DFS ツリーをブラウズすることができる.
リンクa,リンクb(クライアントからはディレクトリとしてみることができる)
に アクセスすると、ユーザーは直接ネットワーク上の共有資源にアクセスす
ることになる。
Windows クライアントは、以前 DFS でなくマウン トされていたものが、 DFS ルートとしてマウントされたり、その逆 を行ったりすると、 リブートする必要がある. よりよい解決方法は、新規の共有として 公開し、DFS ルートとすることである。
現状では制約事項として、msdfs シンボリックリン ク名はすべて小文字で記述される必要がある。
セキュリティのために、DFS ツリーのルートとな るディレクトリは、特定のユーザーのみがそのディレクトリ内でシンボ リックリンクを変更できるように所有者とパーミッションを設定する 必要がある。
あるネットワーク管理者は何故 DFS が機能しなかったかを究明しようとした長い会議 の後に Samba メーリングリストにアドバイスを送った。 彼のアドバイスには注意する価値がある。
“ 私の特定の DFS ルートが機能しない理由を解明するためにいくらかの時間を費やした。 私はシンボリックリンクはすべて小文字で記述するべきであると文書に書かれているこ とに気がついた。シンボリックリンクへのフルパスをも小文字で書き直すことにした。 ”
“設定例: 以下のように定義された共有がある”
[pub] |
path = /export/home/Shares/public_share |
msdfs root = yes |
“そして (DFS クライアントがインストールされた) Windows で、以下のシンボリックリンクをたどることができなかった。 ”
damage1 -> msdfs:damage\test-share
“デバッグレベルを10にして実行して明らかになったこと”
[2003/08/20 11:40:33, 5] msdfs/msdfs.c:is_msdfs_link(176) is_msdfs_link: /export/home/shares/public_share/* does not exist.
“気になる。 私はディレクトリ名
を .../Shares/...
から
.../shares/...
に変更した。 (サービス定義
に伴って) そして、機能するようになった!”
Table of Contents
印刷はユーザーに取ってしばしばミッションクリティカルなサービスである。Sambaは、 Windows ワークステーションからなるクライアントネットワークのために、信頼性が あり、シームレスなこのサービスを提供出来る。
Samba印刷サービスは、ファイルサービス機能と並列に、あるいは専用のサーバー上で、スタンド
アロンかドメインメンバーサーバーで動かす事が出来る。これは、必要に応じて強力に、あるいは
比較的穏やかにセキュアにすることが出来る。設定は簡単になることも複雑になることもある。
有効な認証スキームは、以前の章にあるようなファイルサービス用に説明されたのと基本的に
同じである。全体的に、現在、Sambaの印刷サポートは、多くの場合、付加機能を付けた上で、
Windows NTまたはWindows2000印刷サーバーと完全に対等で、置き換えることが出来る。
クライアントはクライアント上でなじみのあるポイント アンド プリント
メカニズムを通して、ドライバーをダウンロードし、プリンターをインストールできる。
ログオンスクリプト
で実行されるプリンターのインストールは何の問題もない。
管理者はおなじみのプリンター追加ウィザード
を使ってクライアントで
使うことによって、ドライバーのアップロードと管理ができる。更に追加の便利な機能としては、
ドライバーとプリンター管理はコマンド行かスクリプトを通して実行でき、これは、大量の
プリンターがある場合により効率的である。もしも、集中した印刷ジョブの利用状況管理
(訳注:原文はaccount)(すべての単一ページの追跡といろいろな統計レポートに生データを
供給すること)が必要とされる場合、この機能は、Sambaサーバー下の印刷サブシステムとして、
新しい共通UNIX印刷システム(CUPS)によって最もよくサポートされている。
この章では、より現代的なUNIXのBSDとSystem V形式の印刷システムによって実装された、 Sambaの印刷機能の基礎を概観する。この章中の情報の大多数はCUPSにも適用出来る。 もしもCUPSを使っているならば、次の章に飛んでも良いが、すべきことのうち少なくとも いくつかはきっと取りこぼすだろう。さらなる情報は、 CUPS 印刷環境を参照のこと。
Sambaの印刷サポートは、常時それが動作しているUNIX OS上の、インストールされている印刷
サブシステム上に依存している。Sambaは仲介者
である。Windows(か
他のSMB)クライアントから印刷ファイルを受け取り、それをさらなる処理のために実際の印刷
システムに渡す。そのため、両方に接続する必要がある。すなわち、Windows印刷クライアントと
UNIX印刷システムである。それゆえ、異なった機能と異なった形でアクセスされる、種々の
UNIX印刷サブシステムと同様、おのおのが異なって振る舞う種々のクライアントOSの間での違いを
認める必要がある。
この章では伝統的なUNIX印刷方式について取り扱う。次の章では、より最新のCUPSについて、 より詳しく説明する。
現在、Samba管理の側面において、最も問題があることの一つは印刷の設定であることは、Samba メーリングリスト上で投稿されたことでも明らかである。多くの新しいSamba管理者は、Sambaが ある種の印刷処理を実行しているというような印象を持っている。保証するが、Sambaは 何らの印刷処理をも実行しない。何らの印刷フィルタリングも行わない。
Sambaは、ローカルスプール領域にスプールされる、クライアントからデータストリーム (印刷ジョブ)を受け取る。印刷ジョブ全部を受け取ると、SambaはローカルのUNIX/Linux印刷 コマンドを起動し、それに対してスプールされたファイルを渡す。それはローカルの印刷 サブシステムを起動し、正しく印刷ジョブを処理し、プリンターに対してデータを渡す。
Sambaサーバー経由でWindowsクライアントからUNIXプリンターへの印刷がうまくいくためには、 6つ(潜在的には7つ)のステージがある:
プリンター共有に対してWindowsがコネクションをオープンする。
Sambaはユーザーを認証しなければならない。
Windowsがネットワーク経由でSambaのスプール領域に印刷ファイルの コピーを送る。
Windowsはコネクションをクローズする。
Sambaは、UNIX印刷サブシステムの印刷領域経由でファイルを扱う ために印刷コマンドを起動する。
UNIX印刷サブシステムが印刷ジョブを処理する。
印刷ファイルはSambaスプール領域から明示的に削除される必要がある。 これの要素は使用しているマシンのプリントスプーラの構成の設定に依存する。
Sambaの印刷動作を制御するための設定パラメーターは多数ある。それらの概要については
smb.conf
のマニュアルページを参照してほしい。他のパラメーターと同様、グローバルレベル
(一覧上でGとタグが付いているもの)とサービスレベル
(S)パラメーターがある。
これらは明示的に共有定義に記述しなくても良い。
もしもエラーになったならば、(もしも動作させたならば)testparm
ユーティリティでそれを見つけることが出来、そのことを表示する。
これらはsmb.conf
中の[global]
セクションで指定しても良い。この場合、個人毎すべてかサービスレベルの
共有の既定値の動作を定義する(同じパラメーターに対して異なった設定の定義を
を持たない形で提供されるので、グローバルの既定値を上書きする)。
BSD印刷環境での簡単な設定は、簡単な印刷の設定を示して
いる。もしも現在使っている環境と比較して、OSベンダによってあらかじめ設定されている追加の
パラメーターを見つけるかもしれない。以下は、パラメーターについての議論と説明である。この例は
多くのパラメーターを使っていない。しかし、多くの環境において、すべてのクライアントに対して
印刷を有効にする有効なsmb.conf
ファイルを提供するためには、これは十分である。
これは単に例としての設定である。Sambaはすべての設定パラメーターに対して既定値を割り当てて
いる。既定値は保守的でかつ賢明な値となっている。パラメーターがsmb.conf
ファイル中で指定
されたならば、それは既定値を上書きする。rootでtestparm
ユーティリティ
を実行すると、smb.conf
ファイルの設定のように両方の既定値とすべての設定を報告する
機能がある。Testparm
は間違った設定のすべてに対して警告を表示する。
完全な出力は360行を軽く超えるので、その結果をページャープログラムに渡しても良いだろう。
設定ファイルの文法は理解するのが簡単である。その文法について細かいことを知らなくても
よい。この文書のどこかで説明されているが、Sambaはある種の綴りミスには寛容であり
(たとえば、browsableの代わりにbrowseable
など)、綴りは大文字小文字を無視する。論理値に対して、Yes/No
か
True/False
を使うことも出来る。名前のリストは、カンマ、空白か
タブで分離できる。
暗黙で使えるものを含む、Samba中で印刷に関連したすべての(あるいはほとんど全部)を見る
ためには、以下で概要を説明しているコマンドを使う。このコマンドは
testparm
の出力中に現れるすべての
lp
、print
、spool
、driver
,
ports
と[
を検出する。これは、動作している
smbd
の印刷設定の簡便な概要を提供する。このコマンドは個別に作成された
プリンター共有かそれが使えるスプールパスを表示しない。
上記の例で示される設定で設定したSambaの出力は以下の
ようになる:
root#
testparm -s -v | egrep "(lp|print|spool|driver|ports|\[)"
Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" [global] smb ports = 139 445 lpq cache time = 10 load printers = Yes printcap name = /etc/printcap disable spoolss = No enumports command = addprinter command = deleteprinter command = show add printer wizard = Yes os2 driver map = printer admin = min print space = 0 max print jobs = 1000 printable = No printing = bsd print command = lpr -r -P'%p' %s lpq command = lpq -P'%p' lprm command = lprm -P'%p' %j lppause command = lpresume command = printer name = use client driver = No [homes] [printers] path = /var/spool/samba printable = Yes
Sambaの既定値の動作によって暗黙で追加される設定を検査するのは簡単である。 確認:Sambaの将来の関係で重要かもしれない。
Samba-3中のtestparm
は2.2.xのものとは動作が異なる。“-v”
スイッチなしで使うと、実際に書かれた設定のみを表示する。使用している完全な設定を見る
ためにはtestparmに“-v”オプションを追加する。
どのようなステージでもトラブルシュートをする必要があるので、常時、最初にこの点に戻り、
testparm
が期待しているパラメーターを表示するかを検査する。
個人的な経験から忠告すると、load printersパラメーターを
コメントアウトすることを試すこと。もしも2.2.xシステムの動作が、私の環境のようで
あれば、以下のような表示が出る:
root#
grep "load printers" /etc/samba/smb.conf # load printers = Yes # This setting is commented out!!root#
testparm -v /etc/samba/smb.conf | egrep "(load printers)" load printers = Yes
この設定をコメントアウトするとSambaが自分のプリンターを公開させなくすると仮定したが、 実際には引き続き公開している。理由を理解するのには時間がかかった。少なくともこれに よって、もはや馬鹿にされることはない。
root#
grep -A1 "load printers" /etc/samba/smb.conf
load printers = No # The above setting is what I want! # load printers = Yes # This setting is commented out!root#
testparm -s -v smb.conf.simpleprinting | egrep "(load printers)"
load printers = No
パラメーターを明示的にload printers = Noに設定する時 にのみ、Sambaは意向にかなう。そのため、以下を強く推奨する:
コメントアウトしたパラメーターには決して頼らない。
常時、そう動作させたいと意図するものについては、明示的に パラメーターを設定する。
意向を反映しないかもしれない隠れた設定を、見える化するために
testparm
を使う。
以下は最小の設定ファイルである:
root#
cat /etc/samba/smb.conf-minimal
[printers]
この例は、任意のSamba構成ファイルをテストするために、testparm
を
使って表示すべきである。実際、現在動いているシステム(正確に何をやっているか知っている
限り)を変更しないことを勧める。smbd再起動後にのみ変更の影響が
反映されるという仮定に頼ってはいけない!これは本当ではない。Sambaは60秒ごととクライアント
からの接続時に再読込を行う。適用する事を意図しない製品のクライアントのために、変更に
直面しなければならないかもしれない。そのほか、いくつかの興味深いことに注意するとよい。
testparm
は、この最低限の構成を使う時にSambaの印刷設定がどうあるかを
識別するために便利である。以下では、見つけようと思っているものがある:
root#
testparm -v smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"
Processing section "[printers]" WARNING: [printers] service MUST be printable! No path in service printers - using /tmp lpq cache time = 10 load printers = Yes printcap name = /etc/printcap disable spoolss = No enumports command = addprinter command = deleteprinter command = show add printer wizard = Yes os2 driver map = printer admin = min print space = 0 max print jobs = 1000 printable = No printing = bsd print command = lpr -r -P%p %s lpq command = lpq -P%p printer name = use client driver = No [printers] printable = Yes
testparm
は2つの警告を表示する:
[printers]
セクションが印刷可能と指定していない。
どのスプールディレクトリを使うかをSambaに指定していない。
しかし、これは致命的ではなく、Sambaは動作するように既定値を設定する。が、この例を
頼らず、使わないでほしい。これは、自分が何を要求しているかを正確にわかっている設定と
注意深い設計を手助けするために用意された。使用しているシステムからの結果は、異なった
コンパイル時オプションによって構築されたSambaで、いくつかのパラメーターによっていろいろと
変わる。警告:有効な行の行末にコメントサイン
を置いてはいけない。この場合、パラメーターは無視される(行頭にコメントサインを置いたのと
同じになる)。最初にこれは使用しているSambaのバージョンのバグではないかと思った。しかし、
マニュアルページには明確に
パラメーター値の内部の空白は、正確にその通りに保持される
と書いてある。
これは、たとえば以下のような行があると
# これはLPRngを印刷システムとして定義する。 |
printing = lprng |
定義したい値として=
記号の後の文字列すべてを尊重する。これは、不正な
値なので無視され、この場所では既定値が使われる。
拡張BSD印刷環境の設定は、BSD形式の印刷設定中の印刷に
関連した設定のためのより詳細な設定を表示する。下記は、いろいろなパラメーターの議論と
説明である。昔からのUNIX/Linuxマシン上で最も一般的に使われているので、BSD形式の
印刷環境を使う事をした。主に新しいシステムでは、別の章で議論されているCUPSを使う
だろう。例は、既定値で設定されていないという理由で、指定するのが不要なたくさんの
パラメーターを明示的にリストアップする。よりスリムなsmb.conf
を使うことも、
testparm
を使う事も、既定値に設定されているすべてのパラメーターを
smb.conf
から削除して最適化するために、SWAT
を使う事もできる。
Example 21.2. 拡張BSD印刷環境設定
これは設定の例である。OSベンダによって提供されている設定ファイル中でのすべての設定は
ここにはない。明示的に設定されていないSamba設定パラメーターは、既定値で賢明な値に設定
されている。すべての設定を見るには、root
になり、
testparm
ユーティリティを使う。testparm
は
設定の間違いを指摘する。
以下は拡張BSD印刷環境の設定についての議論である。
[global]
セクションは4つの特別なセクションの1つであり
(残りは[homes]
, [printers]
と
[print$]
)、これらはサーバー全体に適用されるすべてのパラメーターを
含んでいる。ここにはグローバルな意味を持つパラメーターのみが配置される。すべての他の
セクションと共有に対しての既定値の設定を定義する、サービスレベルのパラメーターを含む
こともできる。この方法は設定を簡単化し、同じ値を繰り返し設定することを防ぐ(設定
できる個別のセクションか共有内で行えるが、グローバルに設定した共有の設定と他の値の
指定を上書きする)。
BSD(RFC 1179形式かLPR/LPD)として知られてもいる)BSDのために適用出来る
Sambaが使う既定値の印刷コマンドを指定する。一般的に、
printing
パラメーターは、仮定している印刷サブシステム
をSambaに告げる。SambaはCUPS, LPD, LPRNG, SYSV, HPUX, AIX, QNXと PLPを
サポートしている。各システムは異なったprint command
(と他のキュー制御コマンド)を既定値としている。
printingパラメーターは通常サービスレベルの
パラメーターである。[global]
セクション中のここに
含まれた後、異なった設定をしていないすべてのプリンター共有に効果が及ぶ。
Samba-3はもはやSOFTQ印刷サービスをサポートしない。
Sambaにすべての有効なプリンター共有を自動的に作成させる。有効なプリンター
共有はprintcapファイルをスキャンすることで調べる。作成されたすべての
プリンター共有はブラウジングでも表示される。もしもこのパラメーターを使う
場合、各プリンター毎に分割する必要はない。自動的に作成されたプリンター
共有のおのおのは、[printers]
セクション中に
ある設定オプションの設定の複製である
(load printers = no
の設定は、
誰でも見えて使えるようにしたくないいくつかのものをする(leaving out)、
各UNIXプリンターを指定できるようにする)。
設定は通常既定値によって有効になっている(たとえパラメーターがsmb.conf
中で指定されていなくても)。これは、Sambaホストの共有リストの中での
プリンターフォルダー中に
プリンター追加ウィザードが出る原因である(
ネットワークコンピュータか
net view
コマンドで見られる)。これを無効にするには、
明示的にno
と設定する必要がある(コメントアウトは
十分ではない)。プリンター追加ウィザード
は
[print$]
共有にプリンタードライバーをアップロード
させ、それをプリンターに関連づけるか(もしもそれぞれのキューが動作の前に
存在するならば)、以前にアップロードされたドライバーとプリンタードライバーを
交換する)。
ある時間にSambaサーバー上で有効な印刷ジョブを最大100までに設定する。この数よりも 大きなジョブをクライアントが投稿すると、"サーバー上に容量がありません"という エラーメッセージがSambaサーバーからクライアントに返す。ゼロという設定(既定値) は全く制限がない事を意味する。
Sambaに有効なプリンター名ののリストがどこにあるかを告げる。CUPSを使って
いる場合、printcapファイルが書かれているかを確認する。これは
cupsd.conf
ファイル中のPrintcap
ディレクティブによって制御される。
ntadminグループメンバーはドライバーを追加するためとプリンタープロパティを設定することが
出来るようにすべきである(ntadmin
は単なる例としての名前で
ある。有効なUNIXグループ名が必要である)。rootは暗黙的にいつでも
printer adminである。グループ名の前に付く
@
記号は/etc/group
中の名前である。
printer adminは、MS-RPC
(Samba-2.2からの印刷環境開発を参照)
によって提供されるリモート管理インタフェース経由でプリンターのすべてを操作出来る。
より大きなシステムでは、printer adminパラメーターは
通常共有単位に存在するパラメーターである。こうすると、各プリンター共有の管理者に
異なったグループを割り当てる事ができる。
lpqコマンドの結果のキャッシュ時間を制御する。これは、過度にlpqコマンドが 呼ばれる事を防ぎ、高負荷のプリントサーバーの負荷を減少させる。
もしもyes
に設定されると、Windows NT/200x/XPクライアント
のみに(Windows 95/98/MEには関係ない)影響する。このパラメーターの既定値は
No
で(あるいはFalse
)である。
これは、Sambaサーバー上で有効なドライバーがインストールされているプリント共有
では(yes
かtrue
を設定して)
決して有効にしてはならない。より詳細な説明は、
smb.conf
マニュアルページを参照のこと。
printersセクションは2つめの特別なセクションである。もしもこの名前のセクションがsmb.conf
中に現れると、Samba起動時に、printcapファイル中で見つかるすべてのプリンター名に対してプリンター
共有を作成するので、ユーザーはSambaホスト上のprintcapファイル中で定義されている任意の
プリンターに接続できる。このセクションを最低の設定ですべてのプリンターを共有するための、
便利なショートカットとして見なすことができる。これはまた、すべてのプリンターに対する
既定値として適用すべき設定のためのコンテナでもある(より詳細は、smb.conf
マニュアル
ページを参照)。この内側にあるコンテナの設定は共有レベルパラメーターでなければならない。
commentは、クライアントが
ネットワークコンピュータかnet view
コマンド経由でサーバーに問い合わせた時、有効な共有一覧を表示する時に、
共有のそばに表示される。
[printers]
サービスはprintableとして
定義されねばならない。もしもそれ以外を指定すると、
smbdは起動時にロードを停止する。このパラメーターは、このサービスに対して
pathパラメーターで指定したディレクトリ中に、
オープン、書き込みとスプールファイルの投稿を、接続したクライアントに
許可する。これは、ファイル共有とプリンター共有とを区別するために、
Sambaによって使われる。
入力された印刷ファイルをSambaによってスプールするためのディレクトリを 指定しなければならない。UNIX印刷サブシステムの設定中で指定された スプールディレクトリと同じに設定してはならない!パスは通常 stickyビットを設定した、その他に書き込み可能な ディレクトリを指定する。
printable = yesのときは常時
no
に設定する。これは、共有それ自身が、
net view
コマンドか、エクスプローラーのブラウズリスト
中で有効な共有の一覧中で不可視にする(もちろん個々のプリンターを見る
ことは出来る)。
もしも、このプリンターがyes
に設定されているならば、
印刷サービスに接続する時にパスワードを必要としない。アクセスは、
guest accountの権限で許可される。多くのシステム
では、ゲストアカウントは"nobody"という名前にマップされる。このユーザーは
通常空白のパスワード尾持つUNIXのpasswdファイルにあるが、UNIXログインは
無効である。いくつかのシステムでは、ゲストアカウントユーザーは印刷権限を
持たないかもしれない。su - guest
を使い、以下の
システムの印刷コマンドを動かし、使用するシステムのguestユーザー中で
ロギングすることでこれをテストする:
lpr -P printername /etc/motd
guest ok = yesの同義語である。
guest ok = yesを設定すると、
これは本当にここにある必要はない(これは
“同じ共有に対して2つの矛盾している設定が偶然あるときはどうなるか?”
という興味深い質問を導く。答えはSambaが最後に見つけたものが使われる。
testparm
は同じ共有に対して同じパラメーターに対する
異なった設定に対しては注意を喚起しない。異なったユーザー名で
guest account
パラメーターに対して複数の行を
設定することでこれをテストでき、次にtestparmを動作させて、どの行が
Sambaによって本当に使われるかを見る事ができる)。
通常(共有の他のタイプのために)サービスのディレクトリ中で、ユーザーによる ファイルの作成と変更を防止する。しかし、printable サービス中では、常時ディレクトリへの書き込みが許可 されるが(もしもユーザーの権限として接続が許可されているならば)、 それは印刷スプール操作経由でのみである。通常の書き込み操作は許可 されない。
これはread only = yesの同義語である。
もしも、[my_printer_name]
セクションが、
printable = yesを含んでsmb.conf
ファイル中にある
場合、Sambaはこれをプリンター共有と見なして設定する。Windows 9x/Meクライアントは、
共有名が8文字以上の場合、接続かプリンタードライバーのロードで問題が発生するかもしれない。
存在するユーザーかファイル共有の名前と競合する、プリンター共有名を付けてはならない。
クライアントからの接続時に、Sambaは常時その名前を最初に持つものを見つけようとする。
もしもそれが見つかると、これに対して接続を行い、同じ名前を持つプリンター共有には接続
できない!
上記で書いたとおりのコメントである。
このプリンターに対するスプール領域のディレクトリを既定値の代わりに設定する。 これは異なって設定する必要はないが、オプションは有効である。
printer admin定義は、この一般的な[printers]
共有から
明示的に定義されたプリンター共有と違う。もし要求がなければ、可能であればそれを
表示しない。
これは、クライアントが、ネットワークコンピュータで ブラウズするのが便利なように、プリンターをブラウズ可能にする。
20.4.1.2節を参照。
20.4.1.2節を参照。
hosts allowとhosts deny パラメーターを使って特定の数値でのアクセス制御を試す。これは、決して安全な 賭けではない。これは使用しているプリンターをセキュアにする方法ではない。この 行は、最初に評価されるアクセス制御中での特定のサブネットからの、すべての クライアントを許可する。
すべての一覧表示されたホストはここでは許可されない(たとえ許可された サブネットにあったとしても)。見ての通り、NetBIOSホスト名をここに書くのと 同様にIPアドレス名前を付けることが出来る。
このプリンターはゲストアカウントには公開していない。
各セクション(か[printers]
セクション中で)はプリンターを
定義し、print command
は定義されるかもしれない。これは、その
プリンターに対するSambaの印刷スプールディレクトリ中に位置するファイルを処理するコマンドを
設定する。(もしも覚えているならば、このスプールディレクトリはpath
パラメーターで設定される)。通常、このコマンドはSambaが動いているホストの印刷サブ
システムに、適切なシステムの印刷コマンドを使ってスプールファイルを渡す。しかし、もしも
この必要性に要求がなければ、たぶんそうだろう。デバッグかその他の理由で、ファイルの印刷
より何かが完全に異なることを行う事を望んでも良い。例は、プリンティングをデバッグする
ために必要とする時、さらなる調査のために一時的な場所に印刷ファイルをコピーするだけの
コマンドである。もしも、固有の印刷コマンドを作る場合(か印刷コマンドシェルスクリプトの
開発)、Sambaスプールディレクトリからファイルを削除する必要があることに注意をはらうこと。
そうしないと、すぐにディスクがいっぱいになってしまうだろう。
設定ファイル中で明示的に設定されていない場合、Sambaがほとんどの場合、多くのパラメーター について、内蔵の値を使うということは、以前の説明で理解されているかと思う。 print commandでも同じである。既定値の印刷コマンドは printingパラメーターの設定に依存して変わる。 既定値の印刷設定に一覧があるコマンド中で、 Xがp,s,Jのようなものである、 %X形式を持ついくつかのパラメーターに気がつくだろう。 これらの文字は、それぞれプリンターの名前、スプールファイルとジョブIDを表す。これらは、 キーとなる印刷オプションの概要を提供する 既定値の印刷設定中に詳細が説明されているが、 CUPSの場合は特別で、CUPS印刷サポートで 説明があるので、ここに記述はない。
Table 21.1. 既定値の印刷設定
設定 | 既定値の印刷コマンド |
---|---|
printing = bsd|aix|lprng|plp | 印刷コマンドはlpr -r -P%p %s |
printing = sysv|hpux | 印刷コマンドはlp -c -P%p %s; rm %s |
printing = qnx | 印刷コマンドはlp -r -P%p -s %s |
printing = bsd|aix|lprng|plp | lpq コマンドはlpq -P%p |
printing = sysv|hpux | lpq コマンドはlpstat -o%p |
printing = qnx | lpq コマンドはlpq -P%p |
printing = bsd|aix|lprng|plp | lprm コマンドはlprm -P%p %j |
printing = sysv|hpux | lprm コマンドはcancel %p-%j |
printing = qnx | lprm コマンドはcancel %p-%j |
printing = bsd|aix|lprng|plp | lppause コマンドはlp -i %p-%j -H hold |
printing = sysv|hpux | lppause コマンド(...は存在しない) |
printing = qnx | lppause コマンド(...は存在しない) |
printing = bsd|aix|lprng|plp | lpresume コマンドはlp -i %p-%j -H resume |
printing = sysv|hpux | lpresume コマンド(...は存在しない) |
printing = qnx | lpresume コマンド(...は存在しない) |
printing = CUPS
用に、もしもSambaがlibcupsを使うようにコンパイル
されたならば、ジョブの投稿にCUPS APIを使用する(通常使わない位置に自動生成された
printcap ファイルに書き込むために、使用しているシステム中のcupsd.conf
ファイルが設定されている場合、printcap = cupsを
設定するのはよい方法である)。ほかの場合は、Sambaは印刷処理のために、-orawオプションを
付けて、System Vの印刷コマンドにマップする。これはすなわち、
lp -c -d%p -oraw; rm %s
を使うことである。
printing = cups
の場合と、もしもSambaがlibcupsを使うように
コンパイルされた場合、手動で設定したprint commandは何であっても無視される!
サービスに対して印刷ジョブのスプーリングが終了後、print command はスプールファイルを処理するためにsystem()呼び出し経由でSambaによって使われる。 通常指定されたコマンドはホストの印刷サブシステムにスプールファイルを投稿する。 しかし、これが本当にそうであるというべき要求は全くない。印刷サブシステムは それ固有のスプールファイルを削除しないかもしれないので、指定したコマンドは何であっても、 それが処理された後にスプールファイルは消去されるようにすべきである。
伝統的な印刷システムに対して作成した固有の印刷コマンドを使うことについては何ら違いは ない。しかし、固有のものを動かしたくないのであれば(訳注:to roll your own)、各印刷 サブシステムに対してSambaが使う既定値の内蔵コマンドについて熟知すべきである (既定値の印刷設定を参照)。最後のパラグラフに 一覧表示されているすべてのコマンドには%Xという形式のパラメーターが ある。これらはマクロかショートカットで、真のオブジェクトの 名前のためのプレースフォルダーとして使われる。このようなプレースフォルダーを使って、 コマンドを動かしたとき、Sambaは自動的に適切な値に置き換える。印刷コマンドは すべてのSambaマクロ置換を扱える。印刷に関しては、以下の以下のものは特別に扱われる:
%s, %f
スプールファイル名へのパス。
%p
適切なプリンター名。
%J
クライアントから送られたジョブ名。
%c
(もしも分かるならば)スプールされたジョブのページ数。
%z
スプールされた印刷ジョブのサイズ(バイト単位)。
印刷コマンドは少なくとも%s
か%f
のどちらか
1つを使っている必要がある。%p
の使用は任意である。もしも
プリンター名が指定されないと、%p
は印刷コマンドから何のメッセージも
なしに取り去られる。この場合、ジョブは既定値のプリンターに送られる。
[global]
セクション中で指定されると、指定されたprint commandは
固有のprint commandを持たない任意の印刷サービスに対して使われる。もしも、印刷サービスの
ためのprint commandも、グローバルのprint commandも指定されない場合、スプールファイルは
作成されるが処理されない!最も重要なことは、印刷ファイルは削除されず、そのため、ディスク
スペースを消費してしまうと言うことである。
印刷は、nobodyアカウントを使うとき、ある種のUNIXでは失敗するかも
しれない。もしもそのような事態に遭遇したら、代替のゲストアカウントを作成し、印刷権限を
付与する。このゲストアカウントを、[global]
セクション中に、
guest account
パラメーターを使って設定する。
非常に複雑な印刷コマンドを構成することも出来る。印刷コマンドはUNIXシェルに渡される
ようにする必要がある。シェルは通常のように指定されている環境変数を展開できる(UNIXの
環境変数$variable
を、Sambaの印刷コマンドの中で指定するための
形式は%$variable
である)。下記の動作する
print commandの例では、以下は印刷ジョブのログを
/tmp/print.log
に取り、ファイルを印刷し、次にそれを削除する。
セミコロン(“;”)は通常通り、シェルスクリプト中でのコマンドの分離符号である:
print command = echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s |
動作させるシステム上で、通常どのようにファイルを印刷するかに例が依存することを考慮して、 固有のコマンドを変更しなければならないかもしれない。既定値の print commandパラメーターは、printing の設定状態に依存して代わる。他の例は下記の通り:
print command = /usr/local/samba/bin/myprintscript %p %s |
Samba-2.2.xより前は、Windowsクライアントへの印刷サーバーサポートは、 LanMan印刷機能に限定されていた。これは、Windows 9x/Me PCがプリンターを 共有するときのものと同じプロトコルレベルである。2.2.0リリースの最初から、Sambaは ネイティブなWindows NTの印刷方式のサポートを開始した。これらは MS-RPC (Remote Procedure Call)経由で実装されている。MS-RPCは すべての印刷のために、SPOOLSSという名前付きパイプを使用する。
新しいSPOOLSSサポートによって提供される追加の機能は以下を含む:
オンデマンドでWindows 95/98/NT/2000クライアントにプリンタードライバーのダウンロードを サポートする(Point'n'Print)。
Windows NTのAdd Printer Wizard (APW)か Imprintsツールセット経由で プリンタードライバーをアップロードする。
StartDocPrinter, EnumJobs()のような、ネイティブなMS-RPC印刷呼び出しをサポートする (Win32印刷APIについてのより詳細な情報は MSDN documentationを参照のこと)。
スプールされたジョブ情報のための、内部データベースを使用することによる、プリンター
キュー操作のサポートの改善(種々の*.tdb
ファイルによって
実装された)。
Samba-3へのアップデートによって便利になることは、そのプリンターをActive Directory(かLDAP) に公開できることである。
Microsoft Windows NTサーバーとSambaでの操作の間には基本的な違いが存在する。Windows NTは 共有しないローカルプリンターのインストールを許可する。これは任意のWindows NTマシン(サーバーか クライアント)はユーザーがワークステーションとして使えるという不自然な結果となる。Sambaは、 既定値か、プリンター固有の共有経由での特定の定義のどちらかで、有効にしたすべてのプリンターを 公開する。
Windows NT/200x/XP Professionalクライアントは標準SMBプリンター共有を使ってはならない。 それらはMS-RPCを使って他のWindows NTホスト上の任意のプリンターに直接印刷が出来る。これは、 もちろん、クライアントがプリンターリソースを提供しているリモートホスト上で必要な権限を 持っていることを仮定している。プリンターに対してWindows NTによって割り当てられている 既定値のパーミッションは、よく知られたEveryoneグループに印刷の パーミッションを与える(Windows 9x/Meタイプの古いクライアントは、共有されたプリンター への印刷のみ出来る)。
このことが意味することについて多くの混乱がある。次のような疑問がしばしば質問される。 “Windowsクライアントからの印刷をサポートするためにSambaホスト上にプリンター ドライバーをインストールすることは必要か否か?”答えは No で不必要である。
もちろん、Windows NT/2000クライアントではドライバーをローカルに (次にSambaベースの印刷キューに繋ぎ)インストールするためにそれらのAPWも動かすことも できる。これはWindows 9x/Meクライアントによって使われるのと同じ手法である(しかし、 Samba 2.2.0では、プリンターに対する有効なドライバーをSambaサーバーが処理することを Windows NT/2000クライアントが要求させる、というバグがある。これはSamba 2.2.1で 修正されている)。
しかし、これはSambaサーバーの[print$]
共有中にプリンタードライバーを
インストールする新しい機能であり、これはとても便利である。次に、
すべてのクライアント(95/98/MEを含む)はこのプリンター共有に最初に
接続した時にインストールされているドライバーを入手する。この
[print$]
中へのドライバーのアップロード
または供託と、以下の存在するSambaプリンター共有へ、このドライバーを
結びつけることは異なった手段で達成できる:
NT/200x/XP Professionalクライアント上でAPWを動かす(これは95/98/MEクライアントでは動かない)。
Imprintsツールセットを使う。
smbclientとrpcclientコマンド行ツールを使う。
cupsaddsmbを使う(CUPS印刷システムのみ動作し、LPR/LPD、LPRngなどでは動かない)。
Sambaはスプールされたファイルに対してどのような方法でも、これらのアップロードされた ドライバーを使わない。これらのドライバーは、Sambaによってサポートされている “ポイントアンドプリント”メカニズム経由でダウンロード、インストールする クライアントによって完全に使われる。クライアントは、プリンター(かUNIX印刷システム)が 要求する形式に印刷ファイルを生成するためにこれらドライバーを使う。Sambaが受け取る 印刷ファイルは、必要に応じてすべてのさらなる処理のために責任のある、UNIX印刷システムに 渡される。
2.2より前のSambaのバージョンでは[printer$]
という名前の
共有を使う事が出来た。この名前はWindows 9x/Meクライアントがそれによって共有される
プリンターによって作成された、同じ、名前付きのサービスから取られている。
Windows 9x/Meプリンターサーバーは、プリンタードライバーのダウンロードをサポートするために、
ードオンリのアクセス(かつパスワードなし)のサービスを常時用意している。しかし、
Sambaの最初の実装では、printer driver location
という名前の、
共有単位で使われるパラメーターが使えた。これはそのプリンターに関連するドライバー
ファイルの位置を指定した。printer driver
という名前の他の
ラメータは、クライアントに送られるプリンタードライバー名を定義する手段を提供した。
printer driver file
を含むこれらのパラメーターは、Samba-3
では取り除かれ、使う事は出来ない。共有名[print$]
は
ダウンロード可能なプリンタードライバーの位置のために使われる。これは、Windows NT
が動いているPCが、それによって共有されるプリンターによって作成された、
[print$]
という共有名から取られている。Windows NTの
印刷サーバーは、プリンタードライバーのダウンロードとアップロードをサポートするために、
読み書きアクセス(そのACLのコンテキスト中で)を提供する、
[print$]
というサービスを常時提供している。これは
Windows 9x/Meクライアントがこの時点で捨てられるという事を意味するわけではない。
それらにはSambaの[print$]
共有がきちんとサポートする
ものを使える。
プリンタードライバーファイルのアップロード/ダウンロードをサポートするために、まずはじめに
[print$]
という名前のファイル共有を作成しなければならない。
この共有の公開される名前は、Microsoft Windowsクライアント中で埋め込まれている。
これは、プリンタードライバーファイルを検索しようとした時に、正確にこの前のサービスを
探すように、Windowsクライアントがプログラムされているため、改名することは出来ない。
グローバルパラメーターを追加するためにサーバーのファイルを変更し、
[print$]
ファイル共有を作成すべきである(もちろん、
たとえばpathのようないくつかのパラメーターの値は、サイトに
よって適切な値に置き換えるべきである)。[print\$] の例
を参照。
もちろん、pathパラメーターによって名付けられたディレクトリが、 UNIXファイルシステム上に存在するようにしておく必要もある。
[print$]
はsmb.conf
中で特別なセクションである。これは、
潜在的なプリンタードライバーダウンロードに関連する設定を含み、ローカルプリンタードライバーの
インストールのためにWindowsクライアントによって使われる。以下のパラメーターはこの共有
セクションでしばしば必要とされるものである:
共有リスト中に一覧表示された時に、共有のそばにあるコメント(通常Windows
クライアントはそれを見る事ができないが、
smbclient -L sambaserver
の出力中にも表示される)。
UNIXの観点からのWindowsドライバーファイルの保存場所の位置のパス。
[print$]
共有を見せないようにさせる。
cmd
シェルで以下を実行すると:
C:\>
net use g:\\sambaserver\print$
任意のクライアントから引き続き見る事ができる。これは、Windows エクスプローラーから
からでも行う事が出来る。
すべてのゲストユーザーにこの共有をリードオンリにする。クライアント上への
ダウンロードとプリンターのドライバーのインストールを行うためのアクセスは
許可される。guest ok = yes
が必要かどうかは、
どのようにサイトが設定されているかに依存する。もしもユーザーがSamba
ホスト上のアカウントを持つことを許可されているならば、これは何の
問題もない。
もし、Sambaサーバーによって認証されることを、すべてのWindows NTユーザーが
保証されているならば(たとえば、もしも、NTドメインサーバー経由でSambaが
認証するとき、ユーザーはすでにWindows NTセッションのためにログオンするために
ドメインコントローラーによって認証されていた場合)、ゲストアクセスは
不要である。もちろん、ばかげたアカウントとセキュリティについて
心配せずに、ワークグループ環境で印刷を行いたいのであれば、ゲストアクセス
のための共有を設定する。同じように、[global]
セクション中で、
map to guest = Bad User
を追加することを考えるべきである。これを使う前に、このパラメーターが
行う事を理解しておくこと。
誰でもがドライバーファイルをアップロード(あるいはドライバーの設定の変更)する ことは望まないので、この共有を書き込み不可にする。
[print$]
は以前の設定によってリードオンリになって
いるので、write list
も一緒に作成すべきである。UNIX
グループは先頭に“@”が付いたものである。共有上にファイルの
アップデートを必要とするこの一覧にあるユーザーは、(一般的にパブリックな
リードオンリアクセスの例外として)書き込みが許可される。
通常この設定中で管理者レベルのユーザーのみ指名したいであろう。もしもこれが
非rootアカウントである場合、アカウントはグローバルの
printer adminパラメーター中で言及されるべきである。
ファイル共有上の設定についてのより詳細な情報は、smb.conf
マニュアル
ページを参照のこと。
Windows NT印刷サーバーが、複数のクライアントアーキテクチャによってドライバーのダウンロードが
出来るようにするために、[print$]
サービス内にいくつかのサブ
ディレクトリを作成しなければならない(すなわち、pathパラメーターに
よって指定されたUNIXのディレクトリ)。これらはサポートされる各クライアントアーキテクチャ
に一致する。Sambaは同様にこのモデルに追従する。[print$]
共有
それ自身の名前と同じように、サブディレクトリは下記に一覧表示された名前と正確に一致
しなければならない(サポートする必要のないアーキテクチャのサブディレクトリはなくても
よい)。
すなわち、下記のように、[print$]
共有配下に、サポートしたい
各アーキテクチャのためのディレクトリを作成する。
[print$]--+ |--W32X86 # serves drivers to Windows NT x86 |--WIN40 # serves drivers to Windows 95/98 |--W32ALPHA # serves drivers to Windows NT Alpha_AXP |--W32MIPS # serves drivers to Windows NT R4000 |--W32PPC # serves drivers to Windows NT PowerPC
Sambaホスト上に新しいドライバーを追加するためには、2つの条件のうちの1つを真にしておかねばならない:
Sambaホストに接続する時に使われるアカウントはUIDが0でなければならない(すなわちrootアカウント)。
Sambaホストに接続する時に使われるアカウントはprinter adminリスト中に列挙されねばならない。
もちろん、接続されたアカウントは[print$]
下のサブ
ディレクトリファイルを追加するための書き込み許可が必要である。すべてのファイル
共有は既定値で“リードオンリ”に設定されていることを覚えておくこと。
要求された[print$]
サービスと関連したサブディレクトリを作成した
後、Windows NT 4.0/200x/XPクライアントワークステーションの所に行く。
ネットワークコンピュータかマイネットワークを
開き、Sambaホストをブラウズする。所定のサーバーを選択後、その
プリンターとFAXフォルダーに移動する。そうすると、Sambaホスト上で
定義されたプリンター共有にい位置するプリンターの一覧の初期値を見る事ができる。
smb.conf
中に[print$]
共有を無事作成でき、smb.conf
ファイルを
強制的にSambaに再読込させただろうか?であれば問題はない。しかし、新しい機能を使うには
まだもう少し手間がかかる。この共有中にクライアントドライバーファイルをインストールする
必要がある。そのため、まだこの共有は空の状態である。不幸にも、そこにドライバーファイルを
コピーするだけでは十分ではない。正しくインストールする必要があり、そうすると、各
ドライバーに対する適切なレコードがSamba内部データベース中に存在するようになり、
Microsoft Windowsクライアントから要求された正しいドライバーを提供することが出来るように
なる。さらに、控えめに言ってもそれは厳重さが必要である。下記では
[print$]
中にドライバーをインストールする2つの代替方法について
説明する:
任意のUNIXワークステーションから、Sambaのコマンドラインユーティリティ
rpcclient
を、種々のサブコマンド
(adddriver
とsetdriver
など)を組み合わせて
使う。
任意のWindows NT/200x/XPクライアントワークステーションから、GUI (プリンターのプロパティとプリンターの追加ウィザード) を走らせる。
後者のオプションが、おそらくより易しいであろう(たとえプロセスが最初多少奇妙に振る舞うとしても)。
プリンターは、最初、実際のプリンタードライバーがそれに割り当てられていない状態で、クライ アントのエクスプローラーからアクセスされる、Sambaホストのプリンター フォルダーに一覧表示される。既定値で、このドライバーの名前は空の文字列に設定されている。 これは変更しなければならない。NT/2000/XPクライアントから、ローカルの プリンター追加ウィザード(APW)を動かすことで、この作業ができる。
有効なプリンタードライバーのインストールは簡単である。ドライバーを割り当てたいプリンターに
対するプリンターのプロパティを表示させなければならない。Windowsのエクスプローラーを
起動し、ネットワークコンピュータを開き、Sambaホストをブラウズし、
Sambaのプリンターフォルダーを開き、プリンターアイコンを右クリックし、
を選択する。これでプリンターと既定値の
NULL
ドライバーが割り当てられているキューのためのドライバー
プロパティが見えるようになる。そして、“
デバイス設定が表示できません。指定されたプリンターのドライバーがインストールされて
いません。スプーラのプロパティのみ表示されます。ドライバーを今インストールしますか?
”というエラーメッセージが表示される。
ここで、いけない! その代わり、エラーダイアログで をクリックする。これで、 プリンタープロパティウインドウが表示される。ここから、プリンターへのドライバーの割り当ての 手順は公開されている。以下を選べる:
をクリックしてはインストール済みのポップアップリストからドライバーを選択。通常は最初リストは空である。
新しいプリンタードライバーをインストールするために
をクリック(これはAPWを起動する)。
一度APWが起動すると、Windows中でなじみがある、ものと手続きは正確に同じである(Windows NT
上のプリンタードライバーインストール手続きに慣れていることを仮定している)。接続を確認し、
printer admin権限を持つユーザーとしてセットアップ(ユーザーが
権限を持つか分からない場合はsmbstatus
でチェックしてみる)。
クライアントOSに対してWindows NT x86の代わりのプリンター
ドライバーをインストールしたい場合、プリンタープロパティダイアログの共有
タブを使う必要がある。
管理者(root)アカウント(printer adminパラメーターで指定されたもの)
で接続していると仮定すると、さらに、このダイアログを使ってACLと既定値のデバイスの設定
のようなプリンターのプロパティをも修正できる。既定値のデバイス設定のためには、
rpcclient
を使った印刷ドライバーのインストール
に助言が書いてあることを考慮してほしい。
[print$]
にプリンタードライバーをインストールし、有効な方法で
それを設定するための2番目の方法は、UNIXコマンドラインから行う方法である。これは、
4つの異なったステップを必要とする。
要求されたドライバーファイルについての情報を集め、ファイルを収集する。
[print$]
共有の正しいサブディレクトリ中にドライバー
ファイルを置く(おそらくsmbclient
を使うだろう)。
rpcclient
コマンドラインユーティリティを起動し、その
adddriver
サブコマンドを使う。
rpcclient
をもう一度起動し、setdriver
サブコマンドを使う。
以下の節で、これらのステップのおのおのについて詳細な説明を行う。
ドライバーファイルを見つけるためには2つのオプションがある。プリンターに付属のドライバー
CD-ROMの内容を検査することが出来る。CD-ROM上にある*.inf
ファイルの
位置を覚えておく。これは*.inf
ファイルが無いかもしれないので、
出来ない場合もある。残念なことに、最近ではベンダ固有のインストールプログラムを使う
傾向がある。これらのインストールパッケージはしばしば何らかのWindows上での書庫形式
を使っている。更に追加で、インストール処理中にファイル名が改名されるかもしれない。
これは、必要とされるドライバーファイルの識別がとても難しくなることを意味する。
次に、2番目のオプションがある。ドライバーをWindowsクライアント上にローカルに インストールし、インストール後にそれが使うファイル名とパスを調査する (サポートしたい各クライアントプラットフォーム毎にこの手続きを繰り返さなければ ならない。ここでは、すべてのWindows NT/200x/XPクライアントのためにMicrosoftによって 使われる名前である、W32X86プラットフォームのみを 表示する)。
ドライバーファイルを認識する良い方法は、ドライバーのプロパティ ダイアログでテストページを印刷してみることである(全般タブ)。 次に、印刷されたドライバーファイルのリストを見てみる。Windows(とSamba)が ドライバーファイル、データファイル、 設定ファイルと(オプションの) 依存するドライバーファイル(これはWindows NTでは若干変わる)の 何を呼び出しているかを認識する必要がある。次のステップのためにすべてのファイル名を 記録する必要がある。
ドライバーファイル名と関連するパスを迅速にテストする別の方法は、rpcclient
ユーティリティによって提供される。enumdrivers
か
getdriver
サブコマンドを指定し、infoレベルを3
に
してこれを動かす。以下の例では、TURBO_XPがWindows PCの名前である
(この場合、これはWindows XP Professionalラップトップ)。KDE-BITSHOP
という名前のSambaサーバーからTURBO_XPにローカルにドライバーをインストールしたとする。
次に対話的なrpcclient
を動かす。そうすると、
rpcclient />
が表示され、このプロンプトの状態でサブコマンドが入力
出来るようになる。これは練習として残しておこう。次に、1つのサブコマンド行を実行し、
すぐに終了するような-c
オプションをつけてrpcclient
を起動する。これは大量のプリンターとドライバーのために自動作業を行うスクリプトを作成する
時に使う手法である。異なる引用符を使い分けて単語間の異なった空白を解決するように注意:
root#
rpcclient -U'Danka%xxxx' -c \ 'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP
cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3 [Windows NT x86] Printer Driver Info 3: Version: [2] Driver Name: [Heidelberg Digimaster 9110 (PS)] Architecture: [Windows NT x86] Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.DLL] Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.ppd] Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.DLL] Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.HLP] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.DLL] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.INI] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.dat] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.cat] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.def] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hre] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.vnd] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hlp] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01Aux.dll] Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.NTF] Monitorname: [] Defaultdatatype: []
このドライバーは大量の依存ファイル(しかしながらこれは 悪い場合である)を持つことに気がついても良いだろう。また、不思議なことに、 ドライバーファイルはここでドライバーファイル にタグ付けされている。インストールされた、いわゆるWIN40 アーキテクチャに対してまだサポートをしていない。この名前は、Microsoftによって Windows 9x/Meプラットフォームに使われる。もしもこれらをサポートしたいならば、 W32X86(すなわち、Windows NT/2000クライアント) Windows PC上に、それらのために追加でWindows 9x/Meドライバーをインストールしなければ ならない。このPCは、Windows NT,2000あるいはXPで動いたとしても、Windows 9x/Me への機能提供も出来る。
[print$]
共有が通常
ネットワークコンピュータ経由でアクセス出来るので、そこにアクセス
するためにWindowsエクスプローラーからUNC記述を使う事が出来る。Windows 9x/Meドライバー
ファイルはWIN40
ディレクトリの0
という
サブディレクトリで終わる。これらに対するフルパスアクセスは
\\WINDOWSHOST\print$\WIN40\0\
である。
Windows 2000とWindowsXP上のより最新のドライバーは、“2”の代わりに “3”というサブディレクトリ中にインストールされる。Windows NT中で使われる バージョン2のドライバーはカーネルモードで動作する。Windows2000ではこれを変更した。 それは引き続きカーネルモードのドライバーを使えるが(もしAdminによって有効にされれば)、 そのネイティブモードのプリンタードライバーはユーザーモードで動作する。これは、この目的の ために設計されたドライバーを要求する。これらのタイプのドライバーは“3” サブディレクトリにインストールされる。
ここで、以前のステップで認識したすべてのドライバーファイルを収集する必要がある。さて、
どこからそれを得ればよいだろうか?最後のファイルを識別する手段中で調査した、同じ
[print$]
共有とそのPCからそれを検索しないのだろうか?これを
行うのにsmbclient
が使える。getdriver
によって
分かったパスと名前を使える。下記のコマンドライン業は、可読性向上のために、継続行文字を
入れて編集できる:
root#
smbclient //TURBO_XP/print\$ -U'Danka%xxxx' \ -c 'cd W32X86/2;mget HD*_de.* hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 Got a positive name query response from 10.160.50.8 ( 10.160.50.8 ) Domain=[DEVELOPMENT] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]Get file Hddm91c1_de.ABD?
n
Get file Hddm91c1_de.def?
y
getting file \W32X86\2\Hddm91c1_de.def of size 428 as Hddm91c1_de.defGet file Hddm91c1_de.DLL?
y
getting file \W32X86\2\Hddm91c1_de.DLL of size 876544 as Hddm91c1_de.DLL [...]
このコマンドが完了すると、カレントローカルディレクトリにファイルが置かれる。この時点で、
セミコロンで分離した、-c
パラメーターのためにいくつかのコマンドが渡される
ことにおそらく気がつくだろう。これは、smbclient
コマンドが再度終了
する前にリモートのWindowsサーバー上で順番にすべてのコマンドを実行するようにさせる。
WIN40アーキテクチャが、Windows 9x/Me/XPクライアントをサポート
しなければならないために、手続きを繰り返すことを忘れないこと。さらに、それらの
アーキテクチャはWIN40/0/
サブディレクトリにあることを忘れないこと。
これがいったん終わると、Sambaサーバーの[print$]
共有にある、
収集されたファイルを格納するためにsmbclient. ..put
を動作させる
ことができる。
次は、[print$]
共有にドライバーファイルを配置する作業である。この
共有へのUNIXパスはsmb.conf
ファイル中で以前に定義した事を忘れないこと。また、サポート
したい異なったWindowsクライアントタイプのためには、サブディレクトリを作成する。たとえば
もしも、[print$]
が/etc/samba/drivers/
というUNIXパスにマップされているならば、ドライバーファイルは以下のように配置すべきである:
すべてのWindows NT, 2000,と XPクライアント用は /etc/samba/drivers/W32X86/
だが、2
サブディレクトリ中ではない。
すべてのWindows 95, 98,とMeクライアント用は /etc/samba/drivers/WIN40/
だが、0
サブディレクトリ中ではない。
再度、ネットワーク経由で、ドライバーファイルを転送するためにsmbclientを使う。オリジナルの
Windowsインストールに対してgetdriver
を走らせた
事により情報を得た同じファイルとパスを指定する。しかし、ここでは、
Samba/UNIX印刷サーバーの[print$]
共有中に
ファイルを格納する。
root#
smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c \ 'cd W32X86; put HDNIS01_de.DLL; \ put Hddm91c1_de.ppd; put HDNIS01U_de.DLL; \ put HDNIS01U_de.HLP; put Hddm91c1_de.DLL; \ put Hddm91c1_de.INI; put Hddm91c1KMMin.DLL; \ put Hddm91c1_de.dat; put Hddm91c1_de.dat; \ put Hddm91c1_de.def; put Hddm91c1_de.hre; \ put Hddm91c1_de.vnd; put Hddm91c1_de.hlp; \ put Hddm91c1_de_reg.HLP; put HDNIS01Aux.dll; \ put HDNIS01_de.NTF'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 Got a positive name query response from 10.160.51.162 ( 10.160.51.162 ) Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] putting file HDNIS01_de.DLL as \W32X86\HDNIS01_de.DLL putting file Hddm91c1_de.ppd as \W32X86\Hddm91c1_de.ppd putting file HDNIS01U_de.DLL as \W32X86\HDNIS01U_de.DLL putting file HDNIS01U_de.HLP as \W32X86\HDNIS01U_de.HLP putting file Hddm91c1_de.DLL as \W32X86\Hddm91c1_de.DLL putting file Hddm91c1_de.INI as \W32X86\Hddm91c1_de.INI putting file Hddm91c1KMMin.DLL as \W32X86\Hddm91c1KMMin.DLL putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat putting file Hddm91c1_de.def as \W32X86\Hddm91c1_de.def putting file Hddm91c1_de.hre as \W32X86\Hddm91c1_de.hre putting file Hddm91c1_de.vnd as \W32X86\Hddm91c1_de.vnd putting file Hddm91c1_de.hlp as \W32X86\Hddm91c1_de.hlp putting file Hddm91c1_de_reg.HLP as \W32X86\Hddm91c1_de_reg.HLP putting file HDNIS01Aux.dll as \W32X86\HDNIS01Aux.dll putting file HDNIS01_de.NTF as \W32X86\HDNIS01_de.NTF
ヒュー;これはとても大量なタイプ量である!ほとんどのドライバーはより小さい。多くはたった
3つの汎用Postscriptドライバーファイルと1つのPPDのみを持つ。Windowsマシンからの
W32X86
の2
サブディレクトリからファイルを検索した
時、Sambaサーバーの同じサブディレクトリ中に(今は)それらを置かない。この再配置は、
間もなく動く(そして、それらを必要とすべき場合、WIN40/
サブ
ディレクトリ中に、Windows 9x/Meアーキテクチャのためのファイルを置くことを忘れない)、
adddriver
によって自動的に行われる。
次は、所定の場所にファイルがあるかどうかを確認する。これは、smbclient
で行える(が、もちろん、SSH経由でログインし、標準のUNIXシェルアクセスを通して行える)。
root#
smbclient //SAMBA-CUPS/print\$ -U 'root%xxxx' \ -c 'cd W32X86; pwd; dir; cd 2; pwd; dir'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 Got a positive name query response from 10.160.51.162 ( 10.160.51.162 ) Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.8a] Current directory is \\SAMBA-CUPS\print$\W32X86\ . D 0 Sun May 4 03:56:35 2003 .. D 0 Thu Apr 10 23:47:40 2003 2 D 0 Sun May 4 03:56:18 2003 HDNIS01Aux.dll A 15356 Sun May 4 03:58:59 2003 Hddm91c1KMMin.DLL A 46966 Sun May 4 03:58:59 2003 HDNIS01_de.DLL A 434400 Sun May 4 03:58:59 2003 HDNIS01_de.NTF A 790404 Sun May 4 03:56:35 2003 Hddm91c1_de.DLL A 876544 Sun May 4 03:58:59 2003 Hddm91c1_de.INI A 101 Sun May 4 03:58:59 2003 Hddm91c1_de.dat A 5044 Sun May 4 03:58:59 2003 Hddm91c1_de.def A 428 Sun May 4 03:58:59 2003 Hddm91c1_de.hlp A 37699 Sun May 4 03:58:59 2003 Hddm91c1_de.hre A 323584 Sun May 4 03:58:59 2003 Hddm91c1_de.ppd A 26373 Sun May 4 03:58:59 2003 Hddm91c1_de.vnd A 45056 Sun May 4 03:58:59 2003 HDNIS01U_de.DLL A 165888 Sun May 4 03:58:59 2003 HDNIS01U_de.HLP A 19770 Sun May 4 03:58:59 2003 Hddm91c1_de_reg.HLP A 228417 Sun May 4 03:58:59 2003 40976 blocks of size 262144. 709 blocks available Current directory is \\SAMBA-CUPS\print$\W32X86\2\ . D 0 Sun May 4 03:56:18 2003 .. D 0 Sun May 4 03:56:35 2003 ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003 laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003 ADOBEPSU.DLL A 109568 Sat May 3 23:18:45 2003 ADOBEPSU.HLP A 18082 Sat May 3 23:18:45 2003 PDFcreator2.PPD A 15746 Sun Apr 20 22:24:07 2003 40976 blocks of size 262144. 709 blocks available
2
サブディレクトリ(おそらく以前のインストールで)中に、すでに
ドライバーファイルが存在することに注意。いったん新しいドライバーのためのファイルがそこに
あると、クライアント上からそれらを使うことが出来るようにするためからは違ういくつかの
ステップを処理することになる。この時点で行うべき唯一のことは、Windowsエクスプローラーから
print$共有を開いて、ファイル共有から普通のファイルを検索するのと同じように、クライアント
から、それらを検索することである。しかし、それはポイントアンドプリント単位でそれらを
インストールしない。その理由は、Sambaはまだそれらのファイルが特別か、すなわち、
プリンタードライバーファイルかどうかを知らないのと、それらのドライバー
ファイルが属する印刷キューがどれかを知らないということによる。
次に、[print$]
共有中に今アップロードしたファイルの特別な
カテゴリについてSambaに通知する必要がある。これは、adddriver
で
行える。これは、Samba内部のTDBデータベースファイルにドライバーを登録するように表示
してくる。以下のコマンドと出力は、可読性向上のために編集してある:
root#
rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \ "dm9110:HDNIS01_de.DLL: \ Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \ NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ HDNIS01Aux.dll,HDNIS01_de.NTF, \ Hddm91c1_de_reg.HLP' SAMBA-CUPS
cmd = adddriver "Windows NT x86" \ "dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL: \ HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP" Printer Driver dm9110 successfully installed.
このステップの後、ドライバーはプリントサーバー上のSambaによって認識される。このコマンドを 入力するときには特別に注意を払う必要がある。フィールドの順番を交換しないこと。それは 明白である。他の変更は、ドライバーファイルのインストールが成功するかもしれないが、 ドライバーの実行が不可能になる。そのため、注意を払うこと!adddriverコマンドの文法に関する ヒントはマニュアルページにあり、必要ならばより詳細な記述を見ておくこと。
ファイルをドライバーファイルとしてSambaが認識したことを示す表示の1つは、
successfully installed
というメッセージである。
他のものは、adddriver
コマンドによってファイルが
2
サブディレクトリ中に動かされた、という事実である。これは再度
smbclient
コマンドで確認できる:
root#
smbclient //SAMBA-CUPS/print\$ -Uroot%xx \ -c 'cd W32X86;dir;pwd;cd 2;dir;pwd'
added interface ip=10.160.51.162 bcast=10.160.51.255 nmask=255.255.252.0 Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] Current directory is \\SAMBA-CUPS\print$\W32X86\ . D 0 Sun May 4 04:32:48 2003 .. D 0 Thu Apr 10 23:47:40 2003 2 D 0 Sun May 4 04:32:48 2003 40976 blocks of size 262144. 731 blocks available Current directory is \\SAMBA-CUPS\print$\W32X86\2\ . D 0 Sun May 4 04:32:48 2003 .. D 0 Sun May 4 04:32:48 2003 DigiMaster.PPD A 148336 Thu Apr 24 01:07:00 2003 ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003 laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003 ADOBEPSU.DLL A 109568 Sat May 3 23:18:45 2003 ADOBEPSU.HLP A 18082 Sat May 3 23:18:45 2003 PDFcreator2.PPD A 15746 Sun Apr 20 22:24:07 2003 HDNIS01Aux.dll A 15356 Sun May 4 04:32:18 2003 Hddm91c1KMMin.DLL A 46966 Sun May 4 04:32:18 2003 HDNIS01_de.DLL A 434400 Sun May 4 04:32:18 2003 HDNIS01_de.NTF A 790404 Sun May 4 04:32:18 2003 Hddm91c1_de.DLL A 876544 Sun May 4 04:32:18 2003 Hddm91c1_de.INI A 101 Sun May 4 04:32:18 2003 Hddm91c1_de.dat A 5044 Sun May 4 04:32:18 2003 Hddm91c1_de.def A 428 Sun May 4 04:32:18 2003 Hddm91c1_de.hlp A 37699 Sun May 4 04:32:18 2003 Hddm91c1_de.hre A 323584 Sun May 4 04:32:18 2003 Hddm91c1_de.ppd A 26373 Sun May 4 04:32:18 2003 Hddm91c1_de.vnd A 45056 Sun May 4 04:32:18 2003 HDNIS01U_de.DLL A 165888 Sun May 4 04:32:18 2003 HDNIS01U_de.HLP A 19770 Sun May 4 04:32:18 2003 Hddm91c1_de_reg.HLP A 228417 Sun May 4 04:32:18 2003 40976 blocks of size 262144. 731 blocks available
他の検査方法は、印刷関連のTDBファイルのタイムスタンプが更新されたという事 (と、もしも条件がそろえば、そのファイルサイズが増えたこと)である。
この時点で、ドライバーはSambaによって登録された。ほんの少しの時間でこのことを確認できる。 しかし、このドライバーはまだ特定のプリンターに対して関連づけられていない。少なくとも3つの 方法で、ドライバーファイルのステータスを確認できる:
任意のWindowsクライアントの、ネットワークコンピュータによるブラウズから、Samba ホストを検索し、SambaのプリンターとFAXフォルダーを開く。任意の プリンターアイコンを選択し、右クリックしてプリンターの を選択する。詳細タブを クリックする。そのプリンターに対するドライバーを示すフィールドがここにある。ドロップ ダウンメニューでそのドライバーを変更できる(知らずにこれをしないように気をつける こと)。Sambaが理解しているすべてのドライバーの一覧を、これを使うことで見ることが できる。新しいものがその中にあるべきである(クライアントの各タイプはこの固有の アーキテクチャリストの中にのみ見ることができる。もしも各プラットフォーム用に インストールされた各ドライバーが無いならば、Windows95/98/MEかWindows NT/2000/XP を見たときとは、このリストは違っている)。
Windows 200x/XPクライアント(Windows NTではなく)の
ネットワークコンピュータによるブラウズから、Sambaサーバーを
探し、サーバーのプリンターフォルダーを開き、空白の部分(プリンターが
ハイライトされていないようにして)を右クリックする。
を選択する。
ドライバータブ上で、新しいドライバーが一覧表示されていることが
確認できる。この表示は、そのドライバーに属するファイルの一覧を調べるのにも使える
(これはWindows NTでは動作せず、Windows 2000とWindows XPでのみ動作する。
Windows NTは タブを提供しない)。この
ダイアログをより簡単に起動するための代替の方法は、DOSプロンプトで入力する方法
である(もちろん、SAMBA-CUPS
の代わりに使用している
Sambaサーバーの名前を使わなければならない)。
rundll32 printui.dll,PrintUIEntry /s /t2 /n\\SAMBA-CUPS
UNIXプロンプトから、SAMBA-CUPS
になっている場所を
使用しているSambaホストの名前にして、xxxxは、rootに割り当てられている実際の
Sambaのパスワードにして以下のコマンド(かあるいはその変形)を動かす:
rpcclient -U'root%xxxx' -c 'enumdrivers' SAMBA-CUPS
これで、Sambaが知っているすべてのドライバーが表示される。新しいものはこの中に
あるべきである。しかし、[Windows NT x86]
ヘッデイング
配下のもののみが一覧表示され、その部分をインストールしていないため、
[Windows 4.0]
配下はない。3番目のカラムは、他に
インストールされたドライバーを、各サポートしたアーキテクチャ用に、一度に
2度表示する。新しいドライバーはWindows NT 4.0 or 2000
のみに表示される。Windows 95, 98, と Meに存在
しているようにするためには、WIN40アーキテクチャとサブディレクトリに対する
完全な手続きを繰り返さなければならない。
ドライバーに好みの名前を付けることが出来る。前と同じファイルではあるが、異なったドライバー
名を付けてadddriver
ステップを繰り返したいのならば、以下のように
行う:
root#
rpcclient -Uroot%xxxx \ -c 'adddriver "Windows NT x86" \ "mydrivername:HDNIS01_de.DLL: \ Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \ NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP' SAMBA-CUPS
cmd = adddriver "Windows NT x86" \ "mydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\ HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \ HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP" Printer Driver mydrivername successfully installed.
任意のプリントキューにそのドライバーをバインドすることが出来る(しかし、ターゲットの
プリンターに関して意味をなすキューへのドライバーを連携させる事については、責任を
追わねばならない)。繰り返しrpcclient
adddriver
コマンドを実行することは出来ない。おのおのの実行は、それぞれのサブディレクトリ中に
それらを移動することで、[print$]
共有中にファイルを配置して
しまったので、各rpcclient ... adddriver
コマンドの前に
smbclient ... put
を1回実行させなければならない。
Sambaはどのプリンターがどのドライバーに対応しているかを知る必要がある。ドライバーからプリンター
へのマッピングを作成し、この情報をSambaのTDBファイルに格納する。
rpcclient setdriver
はこれを正しく処理する:
root#
rpcclient -U'root%xxxx' -c 'setdriver dm9110 mydrivername'
cmd = setdriver dm9110 mydrivername Successfully set dm9110 to driver mydrivername.SAMBA-CUPS
これはまずい、こういう事は期待していない。この時点では、指定する名前を繰り返す:
root#
rpcclient -U'root%xxxx' -c 'setdriver dm9110 dm9110'
cmd = setdriver dm9110 dm9110 Successfully set dm9110 to driver dm9110.SAMBA-CUPS
コマンドの文法は下記の通り:
rpcclient -U'root%sambapassword
' -c 'setdriver printername
\
drivername
' SAMBA-Hostname
.
これで、ほとんどの仕事が完了したが、まだ全部ではない。
setdriver
コマンドは、Sambaがそのプリンターをすでに知っているときにのみ
成功する。2.2.x中にあるバグは、新しくインストールされたプリンターの認識を妨害する。Samba
を再起動するか、少なくともこれに対応するために、動作中のすべてのsmbdに対してHUPシグナルを
kill -HUP `pidof smbd`
のように送信する必要がある。
Don Quixote曰く、“論より証拠”。印刷することでセットアップした内容の証明が できる。そのため、クライアントPC上にプリンタードライバーをインストールしてみよう。が、 これは思ったよりも簡単ではない。以下で説明する。
特に重要なことは、最初のクライアントPCへのインストール(各アーキテクチャプラットフォーム ごとに)である。一度これが正常に終わると、その後他のクライアントへは、簡単にセットアップ でき、さらなる注意事項は必要ない。以下でフォローすることは、推奨する最初の手順の説明で ある。ここから先はクライアントワークステーションで作業する。そのクライアントからの接続が 書き込みできないbad user nobodyにマップされていないことを確認する。 DOSプロンプトで以下を入力する:
net use \\
SAMBA-SERVER
\print$ /user:root
必要であれば、printer adminで定義している他の有効なユーザーに
rootを置き換える。異なったユーザーですでに接続しているならば、エラーメッセージが表示
される。Windowsは共有の接続からログオフする概念が内容に見えるので、その接続のridを
取得するのに簡単な方法はない(ローカルワークステーションからのログオフと混同しない
ように。それは別の事柄である)。Windows NT/200x上では、workstation
サービスを再起動することで、すべての smb/cifs接続から強制的にログオフすることが
できる。Windows ファイルエクスプローラーとWindows用のMSIEのすべてを閉じることを試みる
ことができる。苦肉の策として、再起動しても良い。自動的な再接続の設定が無いことを
理解すること。別のワークステーションに行ってそこからつなぐ方が簡単かもしれない。
printer adminユーザーとして接続出来た後(Samba上のsmbstatus
コマンドで
これを確認できる)、Windowsワークステーションから以下を実行する:
ネットワークコンピュータを開く。
Sambaサーバーをブラウズする。
そのプリンターとFAXフォルダーを開く。
プリンターを選択して右クリックする。
を選択(Windows NT4/200xでは おそらくそれは であろう)。
新しいプリンター(Sambaサーバー上でprintername
という名前の)が
ローカルのプリンターフォルダー中に現れるはずである
( -> ->
-> プリンターとFAX
で確認)。
おそらくは、印刷テストページを出力しようとしているだろう。全部終わった後、プリンターの
プロパティを開き、 タブ上に、これを行うためのボタンがある。
しかし、やってみると"印刷テストページを印刷できませんでした
"という
エラーメッセージが表示される。これは、そのドライバーに対して有効なデバイスモードセット
がないか、“プリンタードライバーデータ”セットが引き続き不完全状態という理由
による。
有効なデバイスモード
を、ドライバーのために設定する必要がある。
それがどういう意味かはこれから説明する。
Windows NT/200x/XPクライアントからプリンターが完璧に使えるようにするには、以下の作業が 必要である:
これらのどれかが不完全だと、クライアントはせいぜい最適な出力以下しか作成できない。最悪の
場合、プリンターから読めないゴミが出力されたり、何も出なかったりするか、印刷時にエラー
メッセージが出る。Sambaは名前つきの値と、すべての印刷に関連する情報をその内部TDB
データベースファイル(ntprinters.tdb
, ntdrivers.tdb
,
printing.tdb
,と ntforms.tdb
)に格納する。
デバイスモードとプリンタードライバーデータのセットはすべてのプリントキュープロパティの ための基本的な設定の集合体であり、賢明な方法で初期化される。デバイスモードとプリンター ドライバーデータは、印刷サーバー(Sambaホスト)上で健全な値に初期化されるべきであり、 そして、クライアントは直接それらを使い始めることが出来る。どのように初期の健全な 値を設定したらよいだろうか?これは、以下の節で説明されるように、あるNT (か200x/XPクライアント)からドライバーをリモートでアクセスすることで行える。
有効なデバイスモードはprinter adminかrootによってのみ初期化できる
(理由は明白であろう)ことに気がつくこと。デバイスモードはプリンタードライバープログラムそれ
自身を実行することのみで正しく設定できる。SambaはこのWin32プラットフォームドライバー
プログラムを実行できないので、この設定は初期状態ではNULLになる(クライアントが使うためには
有効な設定ではない)。幸いなことに、ほとんどのドライバーは、APWの助けかrpcclientで
[print$]
にアップロードされた時、必要であれば、自動的にプリンター
ドライバーデータを生成する。
最初の有効なデバイスモードの生成と設定は、しかし、Sambaサーバー上にそれをクライアントから 設定するには若干のトリックを必要とする。最も簡単な方法は、サーバーのプリンター上のページの 方向を単純に変更することである。これは求められる効果を起こすために、クライアント上で プリンタードライバープログラムを実行することで十分であり、Sambaサーバーに新しいデバイスモードを 戻す。これを行うためには、Windowsクライアントから、ネイティブなWindows NT/200x/XPプリンター プロパティを、下記のようにして使うことが出来る:
Procedure 21.1. プリンタードライバー設定の初期化手続き
ネットワークコンピュータをブラウズする。
Sambaサーバーを見つける。
SambaサーバーのプリンターとFAXフォルダーを開く。
問い合わせ中の共有プリンターを選択する。
プリンター上で右クリックする(最後の節の説明に従っているならすでにここにいるはずである)。
コンテキストメニューの下部にある
を選択する(もっと上に 引き続き エントリを表示しているなら、直近の節で説明 したように、ドライバーのインストールを完了するためにそれをクリックする必要がある)。詳細タブに移動し、 をクリックする。
ページの設定を
から に変更する(そして戻す)。変更が実際に効果を引き起こすように、ページ方向の変更の確定を確実に行う。
そこに居る間、他のクライアントにおけるドライバーインストール時に適用される、 印刷の既定値を設定してもよい。
この手続きは、クライアントプラットフォーム上でプリンタードライバープログラムを動かし、 正しいデバイスモードをSambaにフィードバックし、そして、それをTDBファイルに格納する。 一度ドライバーがクライアント上にインストールされると、もしもSambaのprinter admin ユーザーであれば、localのプリンターフォルダーに アクセスすることによって、類似したステップを行うことも出来る。ここから、印刷作業は 期待した通りに動作する。
Sambaには、プリンターのための既定値のデバイスモードを生成するための、サービスレベルの
default devmode
という名前のパラメーターがある。ある種のドライバー
機能は既定値のプロパティの値でうまく機能する。その他はクライアントのスプーラサービス
をクラッシュするかもしれない。そのたえm、このパラメーターの使用には注意が必要である。
プリンターに対する有効なデバイスモードをクライアントに作成させることと、使用している
サーバーにそれを格納することは、常時よりよい方法である。
各追加ドライバーは、今説明してきたことと同じ方法でインストールできる。
ネットワークコンピュータ
をブラウズし、Sambaサーバー上の
プリンターアイコンを開き、プリンターを右クリックし、
を選択する。一度これが完了すると(数秒以上はかからない
が、ネットワークに依存するので、分単位でかかるときもある)、クライアント
ワークステーションの、ローカルのプリンターとFAXフォルダー
中に新しいプリンターが現れる。
Windows 200x/XP Professionalワークステーション上で以下のコマンドを使うことによって、 ローカルのプリンターとFAXフォルダーを開くことが出来る。
rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder
一方Windows NT 4.0ワークステーションでは以下のように行う:
rundll32 shell32.dll,Control_RunDLL MAIN.CPL @2
DOS プロンプトウィンドウ内か、 メニュー 中の のどちらかで入力できる。
Sambaサーバー上にドライバーをインストール後(その[print$]
共有中に)、
常時最初のクライアントインストールを正しく完了させねばならない。クライアントから
printer adminとして、まさしくその最初の接続を確立することを
習慣づけるようにすること。これは、以下のように行う:
最初の有効なデバイスモードが実際に初期化される(詳細な説明は 新しいプリンター上のデバイスモードの設定を参照)。
今後のすべてのクライアントインストールのための、使用しているプリンターの既定値の プリンター設定は期待するようになる。
上の方向を横に変更し、適用をクリックし、再度戻すことでこれを行う。 次に、他の設定を変更する(たとえば、常時 A4を使っているときに、 紙のサイズをレターに既定値を変更したくないであろう?既定値として 両面印刷にプリンターを設定したいかもしれないなど)。
Sambaプリンターにrootとして接続するためには、以下のコマンドをWindows 200x/XPのDOS プロンプトから実行する:
C:\>
runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n \\
SAMBA-SERVER
\printername
"
root
のSambaパスワードを入力し、しばらく待ち、
をクリックし、すべてのクライアントで使われる既定値と
すべきジョブオプションを設定する。代替として、printer adminの
設定中のメンバーの中の名前をrootの代わりとして使うことが出来る。
これで、他のすべてのユーザーは同じ方法でドライバーのダウンロードとインストールが
(ポイントアンドプリント
を使って)出来るようになり、既定値も
同じように設定される。もしも、このステップに失敗したら、ユーザーからたくさんの
問い合わせが来ることになるが、たくさんおしゃべりが出来て楽しいことになるだろう。
ドライバーはインストールされた。クライアントによるポイントアンドプリントインストールは 準備ができた。最初のクライアントマシンでダウンロードして使ってみてもよいが、ちょっと 待ってほしい。その前に、有用だと思われる、ちょっとした助言とこつをここで伝授する。 たとえば、前の節で助言したような、プリンターに既定値を設定しなかったとする。利用者は 多くの問題に不満を言うだろう(たとえば、“各ジョブにレターからA4への紙のサイズの 変更を必要とし、それが格納できない”など)。
最後の文は、若干のユーザーと管理者には複雑な気持ちになるかもしれない。何時間もかけて 苦労したのに、設定をセーブできると思ったらそれが出来なかった。それはやった人の 問題ではない。混乱する点は、プリンター名上で右クリックをした時にポップアップされる複数の タブを持つダイアログ中で
を選択したとき、同一である ように見える2つのダイアログが現れ、それぞれは3つの異なった方法でプリンターのオプション 設定を手助けすると言ってくるということである。これの完璧な答えは、Sambaの既定値の ドライバー設定FAQにある:“Windows 200x/XP上ですべてのユーザーで既定値のプリンターオプションを 設定しセーブできない。なぜ?”. どのようにそれを行っている?操作を間違っているのではないか(確かにそれを見つけるのは簡単 ではないが)。すべてを設定するダイアログを起動するのに3つのやり方がある。すべての3つの ダイアログは同じように見えるが、そのうちの1つが意図したものである。すべてのユーザーのために AdministratorかPrint Administratorでこれを行う必要がある。XP Professionalでどのように これを再現したかは以下の通り:
最初の“間違った”方法:
Open the Printers folder.
プリンター(cupshost上のリモートプリンター)を右クリックし、 コンテキストメニューの を選択する。
しっかりとこのダイアログを見て、どのように見えるかを覚えておくこと。
2番目の“間違った”方法:
フォルダーを開く。
プリンター(cupshost上のリモートプリンター) を右クリックし、コンテキストメニューの
を選択する。全般タブをクリックする。
ボタンをクリックする。
新しいダイアログが開く。このダイアログを開いたままにして 親のダイアログに戻る。
3番目の正しい方法(これを最初に行うべきであり、そのあと上記で説明した2番目の方法の ステップ1と2を行う):
詳細タブをクリックする (もしもすべてが“灰色で選択できない”ならば、十分な 権限を持つユーザーでログインしていない)。
ボタンを クリックする。
2つの新しいタブ上のどれかで、 詳細ボタンをクリックする。
新しいダイアログが開く。これを他と比較する。これらは “B.5”からのものとA.3からのものと比較したときに同じか?
2つの設定ダイアログで何らかの違いがあっただろうか?そうではないはずであろう。しかし、
最後のもののみ、ステップC.1からC.6までの処理は、新しいユーザーのために既定値となる、
任意の設定を恒常的に保存する。もしも全クライアントに同じ既定値を設定したいならば、
クライアントがドライバーをダウンロードする前に(上記のAまたはBの手順に従うことで、
クライアントはユーザー毎の既定値を後で設定出来る)、管理者
(printer admin)としてそれらのステップを行う必要がある。
Windows 200x/XPはユーザー毎の既定値設定が出来、その管理者はそれら固有の設定を行う前に
それを提供する。同一に見えるダイアログの親は、そのウィンドウ名が微妙に違っている。
1つはサーバーBar上のプリンターFoo用の既定値の印刷値
(これが必要なもの)と呼ばれ、もう1つは、
“サーバーBar上のプリンターFooの用の印刷設定
”
と呼ばれる。最後のものは、プリンターを右クリックし、
を選択した時に現れるものである。これは、Windows NTの時代に使うことを教わったものであり、
Windows 200x/XPはで同じように試すのはとても自然である。同じように見えるものに到達する
異なったパスがあるとは夢にも思わないだろうが、機能は異なり、すべてのユーザーに既定値を
設定するダイアログである。
(Windows 200x/XP上で)このコマンドを動かしてみる(正しい権限を持つユーザーで):
rundll32 printui.dll,PrintUIEntry /p /t3 /n\\
SAMBA-SERVER
\printersharename
印刷の既定値ボタン(必要としているもの)があるタブを見るには以下のコマンドを実行する:
rundll32 printui.dll,PrintUIEntry /p /t0 /n\\
SAMBA-SERVER
\printersharename
印刷のプリファレンスボタンを持つタブを見るには (システム全体の既定値を設定しない)、DOSプロンプト内でコマンドを実行するか、 -> を選択する。
昨今のSamba 開発フェーズにおいて浮かび上がった問題は、さまざまな種類のプリンターに関して ドライバーのダウンロードサポートが必要なことである。Windows NT の APW(Add Printer Wizard) を使うやり方は(控えめに言っても)筋が良いとはいえない。一人でクリック祭りをやりながら プリンターのインストールをやりつつ反復性緊張症候群(RSS)の苦痛をを味わいたくなければ、 非会話的なスクリプトについて検討する必要があるだろう。
複数のプリンターが同じドライバーを使う場合、rpcclient setdriver
コマンドは
インストールされたキューに結合されたドライバーを設定するために使える。もしもドライバーが
[print$]
で一度更新され、印刷用TDBファイルに登録されると、
複数の印刷キューによって使うことができる。この場合、すべてのキューに対して
(adddriver
を繰り返し実行する必要なしに)
rpcclient
のsetprinter
サブコマンドを繰り返す必要が
ある。以下はどのようにこれを達成するかの例である:
root#
rpcclient
cmd = enumdrivers [Windows NT x86] Printer Driver Info 1: Driver Name: [infotec IS 2075 PCL 6] Printer Driver Info 1: Driver Name: [DANKA InfoStream] Printer Driver Info 1: Driver Name: [Heidelberg Digimaster 9110 (PS)] Printer Driver Info 1: Driver Name: [dm9110] Printer Driver Info 1: Driver Name: [mydrivername] [....]SAMBA-CUPS
-U root%secret
-c 'enumdrivers'
root#
rpcclient
cmd = enumprinters flags:[0x800000] name:[\\SAMBA-CUPS\dm9110] description:[\\SAMBA-CUPS\dm9110,,110ppm HiVolume DANKA Stuttgart] comment:[110 ppm HiVolume DANKA Stuttgart] [....]SAMBA-CUPS
-U root%secret
-c 'enumprinters'
root#
rpcclient
cmd = setdriver dm9110 Heidelberg Digimaster 9110 (PPD) Successfully set dm9110 to driver Heidelberg Digimaster 9110 (PS).SAMBA-CUPS
-U root%secret
-c \ 'setdriverdm9110
"Heidelberg Digimaster 9110 (PS)
"'
root#
rpcclient
cmd = enumprinters flags:[0x800000] name:[\\SAMBA-CUPS\dm9110] description:[\\SAMBA-CUPS\dm9110,Heidelberg Digimaster 9110 (PS),\ 110ppm HiVolume DANKA Stuttgart] comment:[110ppm HiVolume DANKA Stuttgart] [....]SAMBA-CUPS
-U root%secret
-c 'enumprinters'
root#
rpcclient
cmd = setdriver dm9110 mydrivername Successfully set dm9110 to mydrivername.SAMBA-CUPS
-U root%secret
-c 'setdriverdm9110
mydrivername
'
root#
rpcclient
cmd = enumprinters flags:[0x800000] name:[\\SAMBA-CUPS\dm9110] description:[\\SAMBA-CUPS\dm9110,mydrivername,\ 110ppm HiVolume DANKA Stuttgart] comment:[110ppm HiVolume DANKA Stuttgart] [....]SAMBA-CUPS
-U root%secret
-c 'enumprinters'
(説明フィールドの2つのカンマの間に)ドライバーが一覧表示される、空の文字列がある
“dm9110”プリンターが表示される最初のenumprinters
呼び出しを認識するのは簡単ではないかもしれない。setdriver
コマンドの成功後、すべてはうまくいく。
既定値では、Sambaはsmb.conf
中で定義されているすべてのプリンター共有を、
プリンターフォルダーに表示する。また、このフォルダー中にWindows NTの
プリンター追加ウィザードアイコンも配置される。APWは下記の条件の時にのみ表示される:
接続したユーザーは管理者権限つきでOpenPrinterEx(\\server)
を
正常に実行できる(すなわち、root又はprinter admin)。
Windows 200x/XP DOSプロント内で下記を試してみる:
runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\
SAMBA-SERVER
\printersharename
をクリックする。
... は下記の設定を含む show add printer wizard = yes (既定値) default)。
APWではいろいろなことが出来る:
新しいドライバーをSambaの[print$]
共有にアップロードする。
存在している印刷キューに(ただしまだドライバーがない)アップロードされたドライバーを関連づける。
存在する印刷キューに対して、以前にアップロードされたものと、現在使っているドライバーを、交換する。
Sambaホストに、完全な形で新しいプリンターを追加する(動作する add printer commandと組み合わせる場合のみ。 プリンターフォルダーからエントリを削除するための delete printer commandも提供してもよい)。
最後のもの(プリンターの追加)はその前のものよりもより多くの努力を必要とする。Sambaサーバーに
正しくプリンターを追加するのにAPWを使うためには、add printer command
に値が定義されている必要がある。プログラムホックは、正しくUNIX印刷システム(すなわち
/etc/printcap
、/etc/cups/printers.conf
か
他の適切なファイル)と、必要であればsmb.conf
にプリンターを追加しなければならない。
クライアントからAPWを使うとき、名前が付いたプリンター共有が存在しない場合、smbdは
add printer commandを実行し、新しいプリンター共有を配置する
ために、再度検索する。もしも共有がやはり定義されていないのであれば、クライアントに
"アクセスが拒否されました"が返る。ユーザーが接続している
状態においてのadd printer commandの実行は、rootアカウント
の必要はない。map to guest = bad userは
間違った権限で書き込みが出来なくなる接続をしてしまうだろう。
smbstatus
コマンドを使ってこのことを検査すべきである。
間違った認証情報で接続してしまった場合、すべてのエクスプローラー画面を閉じ、リブート する以外に、この状況を解決する方法はない。
net use \\SAMBA-SERVER\sharename /user:root
を使うと以下の
エラーメッセージが表示される:
“サーバーか共有リソースへの、複数の接続か、同じユーザーによっていくつかの
ユーザー名を使う事は許可されない。特にサーバー、共有リソースへのすべての接続を
切断し再度試してみる。”
“ネットワークドライブへの割り当て”->
\\SAMBASERVER\\print$
->z:
へのすべての
試みは、以下のようなメッセージがしつこく表示される:
“このネットワークフォルダーは現在異なった認証情報(ユーザー名とパスワード)の元で
接続されている。異なったユーザー名とパスワードで再度接続するために、この
ネットワーク共有への接続まず初めに切断する。”
そのためすべての接続をクローズする。そして再実行する。そうすると同じメッセージが出る。
smbstatus
を使ってSamba側でチェックを行う。するといくつか接続
されているのが分かる。それらをkillする。そうしてもクライアントは同じメッセージを出す。
デバッグレベルを上げて、再接続してsmbd.logをチェックする。ログ中に1行ではない、
いくつかのエラーメッセージがある事が分かる。何らかの接続があったかどうかを考えて見始める。
接続するときの状況を見るため、wiresharkかtcpdumpを走らせてみる。結果はこうなる:
たくさんのデータがネットワーク上に出ている。Windowsは引き続きエラーメッセージを表示して
いる。エクスプローラーのウィンドウをクローズして、再度起動する。再度接続すると今回は
うまくいった!Windowsは接続情報をどこかにキャッシュしているように見え、それは最新状態に
していない(不幸な場合、エラーメッセージを除去するためにリブートの必要があるかもしれない)。
クライアントからサーバーへのすべての接続を強制的に終了する最も簡単な方法は以下を実行する:
C:\>
net use * /delete
これは、マップされたドライバーすべても切断し、要求に応じて新しい接続が出来るようにする。
特定のドライバーに帰属するファイルについて注意するときにはきわめて注意深くする必要がある。
ドライバーバージョン“0”(Windows 9x/Me用で[print$]/WIN/0/
に入るもの)とドライバーバージョン2
(Windows NTのカーネルモード
ドライバーで、[print$]/W32X86/2/
に入るもので、Windows 200x/XPでも
使われる)と、ドライバーバージョン“3”(非カーネルモードドライバーで、
[print$]/W32X86/3/
に入るもので、Windows NTでは使われない)のための
ファイルを混同してはならない。これら異なったドライバーのバージョンは同じ名前のファイルを
含んでいるが実際には全く異なることがとても多い。Sambaからenumdrivers
コマンドで、大小文字が混じったか、小文字のみで表示されている間、もしもそれらをWindows
エクスプローラー(%WINDOWS%\system32\spool\drivers\W32X86\
内にある)で
見る時、大文字で名前を見ることになるので、とてもこれらを混同しやすくなる。もしも、
rpcclient
とサブコマンドを使い、手動でそれらをインストールした場合、
何のエラーメッセージもなしに成功する。その後、クライアント上にインストールしようと
したとき、このサーバーはプリンターに対する適切なドライバーを持っていない
というエラーメッセージを受け取ることになる。
以下は例である。しっかりと数多くのファイルに対して、その名前と綴りを確認し、バージョン2と
3の構成において、その違いを見いだすことが求められる。注意:バージョン0には40の
依存するファイル
があるので、紙面節約のためにそれらは削除してある:
root#
rpcclient -U 'Administrator%
Printer Driver Info 3: Version: [3] Driver Name: [Canon iR8500 PS3] Architecture: [Windows NT x86] Driver Path: [\\10.160.50.8\print$\W32X86\3\cns3g.dll] Datafile: [\\10.160.50.8\print$\W32X86\3\iR8500sg.xpd] Configfile: [\\10.160.50.8\print$\W32X86\3\cns3gui.dll] Helpfile: [\\10.160.50.8\print$\W32X86\3\cns3g.hlp] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aucplmNT.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\ucs32p.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\tnl32.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussdrv.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cnspdc.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussapi.dat] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3407.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\CnS3G.cnt] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBAPI.DLL] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBIPC.DLL] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcview.exe] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcdspl.exe] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcedit.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm.exe] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcspl.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cfine32.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcr407.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\Cpcqm407.hlp] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm407.cnt] Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3ggr.dll] Monitorname: [] Defaultdatatype: [] Printer Driver Info 3: Version: [2] Driver Name: [Canon iR5000-6000 PS3] Architecture: [Windows NT x86] Driver Path: [\\10.160.50.8\print$\W32X86\2\cns3g.dll] Datafile: [\\10.160.50.8\print$\W32X86\2\IR5000sg.xpd] Configfile: [\\10.160.50.8\print$\W32X86\2\cns3gui.dll] Helpfile: [\\10.160.50.8\print$\W32X86\2\cns3g.hlp] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\AUCPLMNT.DLL] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussdrv.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cnspdc.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussapi.dat] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3407.dll] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\CnS3G.cnt] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBAPI.DLL] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBIPC.DLL] Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3gum.dll] Monitorname: [CPCA Language Monitor2] Defaultdatatype: []secret
' -c 'enumdrivers 3' 10.160.50.8
もしも“バージョン 2”ファイルと“バージョン 3”ファイルを異なった テキストファイルに書き込み、その結果を比較すると以下のようになる:
root#
sdiff 2-files 3-files
cns3g.dll cns3g.dll iR8500sg.xpd iR8500sg.xpd cns3gui.dll cns3gui.dll cns3g.hlp cns3g.hlp AUCPLMNT.DLL | aucplmNT.dll > ucs32p.dll > tnl32.dll aussdrv.dll aussdrv.dll cnspdc.dll cnspdc.dll aussapi.dat aussapi.dat cns3407.dll cns3407.dll CnS3G.cnt CnS3G.cnt NBAPI.DLL NBAPI.DLL NBIPC.DLL NBIPC.DLL cns3gum.dll | cpcview.exe > cpcdspl.exe > cpcqm.exe > cpcspl.dll > cfine32.dll > cpcr407.dll > Cpcqm407.hlp > cpcqm407.cnt > cns3ggr.dll
だまされてはいけない!各バージョン用の、同一の名前のドライバーファイルは、サイズを 比較して分かるように、その内容が異なっているかもしれない:
root#
for i in cns3g.hlp cns3gui.dll cns3g.dll; do \ smbclient //10.160.50.8/print\$ -U 'Administrator%xxxx' \ -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i"; \ done
CNS3G.HLP A 122981 Thu May 30 02:31:00 2002 CNS3G.HLP A 99948 Thu May 30 02:31:00 2002 CNS3GUI.DLL A 1805824 Thu May 30 02:31:00 2002 CNS3GUI.DLL A 1785344 Thu May 30 02:31:00 2002 CNS3G.DLL A 1145088 Thu May 30 02:31:00 2002 CNS3G.DLL A 15872 Thu May 30 02:31:00 2002
多くの例では、上記の例よりももっと違っている。結論:各ドライバーバージョン用の正しいドライバー ファイルを注意深く選択しなければならない。名前だけに頼っても、異なったドライバー バージョンに属するファイルを交換してもいけない。
Windows NT/2000印刷サーバーは各プリンターに対してポートを結びつける。これらは通常、
LPT1:
、COM1:
、FILE:
のような形式である。Sambaもプリンターに結びついたポートという概念をサポートせねば
ならない。既定値では、システム上“Sambaプリンターポート”という名前の1つの
プリンターポートのみが存在する。Sambaは印刷するために、“ポート”のようなものは
実際に必要はしていない。むしろ、これはWindowsクライアントの要求である。この情報を要求する
時、有効なポートについて告知されることを強く要求する。それ以外だとエラーメッセージを表示
する。そのため、SambaはWindowsクライアントに支障がないよう、ポート情報を偽装する。
Sambaは内部的に同等のプリンタープーリング
という概念をサポートして
いない。プリンタープーリングは論理プリンターを複数のポートに、ロードバランシングか
フェイルオーバーのように割り当てるものである。
もしも何らかの理由か、他の理由で(Sambaでそういうことが出来るか、ユーザーと管理者は知る べきではないが)複数のポートを定義する要望がある場合、システム上のポートの一覧を生成する 外部プログラムを定義するために使えるenumports commandを設定する。
印刷はうまくいっているが、まだ問題がある。ほとんどのジョブの印刷はうまくいくが、 いくつかは全く印刷できない。いくつかのジョブはうまくいっていないように見えるフォントの 問題を抱えている。いくつかのジョブは速やかに印刷するが、いくつかはとても遅い。それら 全部について触れることは出来ないが、 CUPSによる印刷の章の “間違ったPostscriptドライバー設定の防止”、 クライアント上の危険なPostscriptドライバー設定の防止 の短い節を読むことを推奨する。
ImprintsツールセットはWindows NT APWの同等品をUNIXで提供する。完全な情報は、Imprints のソースディストリビューションを含むドキュメントがある、 ImprintsのWebサイトを参照して ほしい。この節は、Imprintsの機能について簡単な紹介を提供するのみ行う。
不幸にも、Imprintsツールセットはもはやメンテナンスされていない。2000年12月から プロジェクトは新しいメンテナを必要としている。持つべきスキルのうち最も重要なものは PerlのコーディングとSambaで使うMS-RPCベースの印刷についての興味である。もしも ボランティアを希望するならば、Sambaテクニカルメーリングリストで希望を調整してほしい。 ツールセットはいまだに便利であるが、使うために準備されているパッケージは古いプリンター モジュールに対してのもののみである。Imprintsが持つべきであるならば、より更新された プリンタードライバーのパッケージが必要である。Imprintsにツールセットに関する情報は Imprintsホームページから 得ることが出来る。
Imprintsは以下をサポートするためのツールの集合体である:
Windows NTと 95/98プリンタードライバーパッケージに関連する集中した情報のリポジトリを提供する。
Imprintsプリンタードライバーパッケージを作成するためのツールを提供する。
中央のインターネット(又はイントラネット)Imprintsサーバーリポジトリからプリンタードライバーを 得、リモートのSambaとWindows NT印刷サーバー上にそれをインストールする事を提供する。
プリンタードライバーパッケージの作成手順はこのドキュメントの範囲外である(より詳細は、Sambaの ディストリビューションに含まれているImprints.txtを参照)。簡単に言うと、Imprintsドライバー パッケージは、ドライバーファイル、関連するINFファイルとクライアントがインストールするのに 必要な制御ファイルを含む、gzipされたtar形式ファイルである。
Imprintsサーバーは、実際には、標準HTTPメカニズム経由で問い合わせを受けることが出来る データベースサーバーである。データベース中の各プリンターエントリは、実際にダウンロード するパッケージを示すURLに関連づけられている。各パッケージは、実際にダウンロードした ものが、Imprintsデータベース中で参照されるものかどうかを検査できるよう、GnuPGを使って デジタル署名されている。このセキュリティ検査を無効にしないことを強く推奨する。
Imprintsクライアントに関連するさらなる情報は、Imprintsソースパッケージ中にある、
Imprints-Client-HOWTO.ps
という文書ファイルに書いてある。
Imprintsクライアントインストールは以下の2つの形式がある:
コマンドラインPerlスクリプト一式。
コマンドラインPerlスクリプトへのGTK+ベースのグラフィカルインタフェース
(両方の形式による)クライアントのインストールは、リモートSambaとWindows NTプリントサーバー 上へのダウンロードとドライバーのインストールという意味と同じような、既存のプリンターモデル名 の一致リストのための、Imprintsデータベースサーバーに問い合わせる手段を提供する。
基本的なインストール手順は4つのステップがあり、Perlコードはsmbclientとrpcclientを包み こんでいる。
与えられたドライバーがサポートする各アーキテクチャに対して:
rpcclient: リモートサーバー上の適切なアップロードディレクトリを取得する。
smbclient: ドライバーファイルをアップロードする。
rpcclient: AddPrinterDriver() MS-RPCを発行する。
rpcclient: 実際にプリンターの作成を行うためにAddPrinterEx() MS-RPCを発行する。
Imprintsツールセットを実装するときに発生した問題の1つは、数多くサポートされている クライアントアーキテクチャ間での名前空間の問題であった。例えば、Windows NTには “Apple LaserWriter II NTX v51.8”という名前のドライバーを含んでいるが、 Windows 95はこのドライバーの対応するバージョン“Apple LaserWriter II NTX” を呼び出す。
問題は、プリンターに対してどんなクライアントドライバーをアップロードするかということを どのようにして知るかと言うことである。抜け目がない読者は、Windows NTのプリンター プロパティのダイアログのみが、そのプリンタードライバー名に空白を含んでいることを覚えて いるだろう。下記のWindows NT 4.0システムレジストリを簡単に見てみると、
HKLM\System\CurrentControlSet\Control\Print\Environment
これは、Windows NTが常時 NTドライバー名を使うことを明白にしている。これは、Windows NTが 少なくともWindows NTバージョンのプリンタードライバーが存在することを常時要求しているので 問題はない。Sambaは内部的にはそれを要求しない。そのため、 “すでにインストールされていないのに、なぜNTドライバー名を使うことが出来るのか?” という疑問が生じるだろう。
この限界を回避する方法は、すべてのImprintsドライバーパッケージがIntel Windows NTと95/98 プリンタードライバーを含み、そのNTドライバーが最初にインストールされることを要求することである。
以下のMS Knowledgeベースの記事は、Windows 2000クライアントを扱う必要がある場合に何らかの
手助けになるかもしれない。
ユーザーによる操作なしで Windows にプリンターを追加する方法
(Microsoft KB 189105(日本語))。
これは又Windows XP Professionalクライアントにも適用できる。この節で示すアイデアの概要は、
ネットワークとローカルプリンターとそのドライバーをインストールするために適用できるコマンド
ライン手法を説明するこの記事によって触発されたものである。これは、ログオンスクリプトと
統合すると最も便利である。コマンドプロンプト(DOSプロンプト
)で
以下のようにタイプすることにより、どのようなオプションが有効かを見ることができる:
rundll32 printui.dll,PrintUIEntry /?
すべての有効なコマンドラインスイッチを表示するウィンドウがポップアップする。 大規模な 例題リストも提供される。これは、Windows 200x/XPのみである。Windows NT上では動作 しない。Windows NTはそれぞれねリソースキット内である種の他のツールをおそらく 持っている。各行が実際に何をするかについての簡単な説明がある、クライアントログオン スクリプトが含んでも良いかもしれないものについての助言は以下の通り(これはSamba 経由で200x/XP Windowsクライアントがプリンターにアクセスする場合に動作し、さらに、 Windowsベースのプリンターでも同様である)。
rundll32 printui.dll,PrintUIEntry /dn /n "\\cupsserver\infotec2105-IPDS" /q
rundll32 printui.dll,PrintUIEntry /in /n "\\cupsserver\infotec2105-PS"
rundll32 printui.dll,PrintUIEntry /y /n "\\cupsserver\infotec2105-PS"
コマンドラインパラメーターで使われるパラメーターの一覧である:
ネットワークプリンターを削除する。
表示を抑制する。
プリンターに名前を付ける。
ネットワークプリンター接続を追加する。
プリンターを既定値のプリンターにする。
1行目ではinfotec2105-IPDSという以前に存在していた可能性の
あるネットワークプリンターを削除する(CUPSに変換された、サーバーから削除されたLPRngの
ネイティブなWindowsドライバーで使われていた)。終わりにある/q
は、ポップアップする確認あるいはエラーダイアログボックスを抑制する。これらは
ユーザーログオンについては提供されない。
2行目では、新しいプリンターinfotec2105-PS(実際には同じ物理
デバイスであるが、新しいCUPS印刷システムによって動作し、CUPS/Adobe PSドライバー
と関連づけられる)を追加する。プリンターとそのドライバーはユーザーのログインに先立って
追加されねばならない(すなわち、この章の前の方で説明した手順か、
cupsaddsmb
を動かすことによって)。ドライバーはユーザーがログイン
しようとしているときに、クライアントPCに自動的にダウンロードされる。
3行目では、この新しいネットワークプリンターを既定値のプリンターに設定する(この方法を 使っていくつかのプリンターが存在するかもしれなく、また、そのうちのいくつかは同じ ようにローカルであってもよいので、既定値のプリンターを決める事が必要となる)。 既定値のプリンターの選択は、もちろん、異なったユーザーでは異なっても良い。
2番目の行は、もしもプリンターinfotec2105-PSがすでに
cupsserver
上のプリントキューで動作していて、もしも
プリンタードライバーがSambaのドライバーリポジトリである[print$]
中に、すでにきちんとアップロード(APW
,
smbclient/rpcclient
かcupsaddsmb
経由で)
されている場合にのみ動作する。バージョン3.0より前のある種のSambaのバージョンでは、
プリンターインストール後とドライバーアップロード後にsmbdの再起動を要求する。そうでないと、
スクリプト(かその他のルライアンとドライバーダウンロード)は失敗する。
ログオンスクリプトからの、インストールされたネットワークプリンターの存在をテストする簡単な 方法は無いので、わざわざ調べる必要はない。ユーザーログイン時に毎回インストールの削除/ 再インストールが出来るようにしておくこと。それはとても短時間である(1から2秒くらい)。
ほかにこの件に関する有用な情報は以下の通り:
全部のユーザーログイン時に自動的に、任意のプリンター既定値の設定変更を適切に設定する。
異なったワークステーションからドメインにユーザーが“ローミング”でログイン出来るようにする。
各ユーザー毎にネットワークプリンターがインストールされるので、これにより、インストールの 最新性を保持する作業をより単純化する。ログイン時に数秒余計にかけることはほとんど 目立たないだろう。プリンターは、クライアントからユーザーが介入する必要性なしにサーバー上で 集中して追加、変更と削除ができる(ログインスクリプトは最新性を保持する必要はある)。
addprinter
コマンドはSambaによって実行されるシェルスクリプトか
プログラムとして設定できる。これはSambaプリントサーバーに対してクライアントからAPWを
走らせることによって起動される。APWはユーザーにいくつかのフィールドを埋めることを
要求する(それはたとえばプリンター名、使用するドライバー、コメント、ポートモニターなど)。
これらのパラメーターはAPWによってSamba上に渡される。もしも、addprinterコマンドが
新しいプリンターを作成できるように(旧式のシステム上で、適切なprintcapエントリを書くか、
より新しいシステム上でlpadmin
コマンドを実行することによって)と、
それに関連する共有を作成するように設計されていた場合、APWはSamba上とUNIX印刷
システム上に、結果として新しいプリンターを作る!
基本的なNT形式のプリンタードライバー管理は2.2.xリリースから3.0ではほとんど変更はなかった (小さな改善はたくさん適用されたが)。特に、設定中で廃止されるパラメーターを使うのをやめる、 前述の助言に従うならば、移行はとても簡単である。既存の2.0.x設定か、Samba 2.2で Windows 9x/Me形式の印刷形式を継続したいのであれば、それはもっと努力が必要となる。 適切なリリースノートとSamba-2.2.xのHOWTO文書を読んでほしい。以下のいくつかの方法に 沿うことが出来る。移行のための可能なシナリオは以下の通り:
新しい Windows NTプリンターとドライバーサポートについて学習し、使う必要がある。以前
使っていたパラメーターprinter driver file
,
printer driver
とprinter driver location
はもはやサポートされない。
もしもWindows NTプリンタードライバーサポートを利用したいのであれば、新しい設定の ために、Windows 9x/Meドライバーを新しいものへ移行する必要がある。
存在するprinters.def
ファイル(削除されたパラメーター
printer driver file
中で指定されているもの)はもはやSamba-3
では動作しないので、smbdは[print$]
中とTDBファイル中の
追加の設定だけで、プリンターのためのWindows 9x/Meドライバーファイルを捜そうとする。
もしもそれが失敗すると、(2.2.xが使うように)printers.def
(とすべての関連するパラメーター)を使うようにはならない。
make_printerdefツールは削除され、これに関する下位互換性はない。
使用しているSambaホスト上のプリンター用の
[print$]
共有中にWindows 9x/Meドライバーをインストールする
必要がある。ドライバーファイルは[print$]
の
“WIN40/0”サブディレクトリ中に格納され、その他の設定と情報は印刷
関連のTDBファイル中に格納される。
もしも、存在するprinters.def
ファイルを新しい設定中に移行
したいならば、現在唯一の解は、NTドライバーと9x/Meドライバーをインストールするために、
Windows NT APWを使うことである。これはsmbclientとrpcclientを使うスクリプトで
行える。その例は、
Imprints
のWebサイト上にあるImprintsクライアントインストールを参照。また、
CUPS 印刷環境中のrpcclientの使用法についての
議論も参照のこと。
この件に関しては、 リモートとローカル管理Netコマンドでも 触れられている。もしもこの機能に関しての文書の更新をボランティアとして手助けしてくれる のであれば、John H. Terpstraに連絡を してほしい。
UNIXシステムで有効な(とほとんどの場合、/etc/shadow
というファイルに
1方向ハッシュ形式として格納される)rootパスワードと、Samba認証時に使うパスワードと混同
しないこと。SambaはUNIXパスワードを知らない。Sambaリソースへのrootアクセスは最初に作成
されなければならないSamba用のrootアカウントを必要とする。これは以下のように、
smbpasswd
を使って行える:
root#
smbpasswd -a root
New SMB password: secret
Retype new SMB password: secret
存在するUNIX印刷システムスプールディレクトリをSambaスプールディレクトリに使っては
ならない。それは、簡単で場所を節約できるように見えるが、これは問題を引き起こす。
2つは分離せねばならない。UNIX/Linuxシステムプリントスプールディレクトリ(すなわち
/var/spool/cups
)は通常cups
や
lp
のような非特権ユーザーによって所有される。さらに追加で、
スプールディレクトリのパーミッションは、通常所有者とグループに対して制約されて
いる。別の言い方をすると、Sambaスプールディレクトリは全員に対して書き込み可能で、
一時スプールファイルの所有者のみがファイルを変更したり削除できるようにする、
't'ビットを設定すべきである。
UNIX/Linuxホスト上で使う印刷スプールシステムのタイプに依存するので、スプール管理 アプリが見つける、管理されているジョブキューの一部でないファイルは削除される。 これは、ジョブが(Sambaによって)このディレクトリ中にスプールされて消えてしまう現象の 説明になるだろう。
Table of Contents
cupsomatic/foomatic
の役割mime.convs
cupsaddsmb
用のsmb.conf
の準備*.tdb
ファイルcupsaddsmb
が、新しくインストールしたプリンターで動かない/var/spool/samba/
のアクセス許可が、再起動後毎回リセットされる共通UNIX印刷システム(CUPS)は 現在非常に一般的になってきている。すべての主要なLinuxディストリビューションは 現在既定値の印刷システムとしてこれと導入している。ただ、残念ながら、これは まだ非常に取っつきづらいツールである。ほとんどの場合、これはちゃんと動く。 多くの人は、これが動いている間は、その中身を覗きたくなく、それを “ブラックボックス”として扱う傾向がある。しかし、ひとたび 小さな問題が発生すると、どこからデバッグしていいかということを見つける 困難が生じる。CUPSに関連したより多量の情報もある、 旧式の印刷サポートも参照のこと。
CUPSは固有で強力な機能を持っている。その基本機能は容易に把握でき、 かつそれらは新しい。これは他のものと違い、より現代的な印刷システムであり、 この新しいシステムで印刷することに関する以前の知識を適用しないことが最も良い。 むしろ、最初からCUPSを理解することをすべきである。この文書はCUPSの完全な理解 を手助けする。まず基本的な点から最初に始めよう。
CUPSは印刷スプールシステムというもの以上である。これは、新しいインターネット印刷 プロトコル(IPP)に従う完全な印刷管理システムである。IPPは産業製品であり、 ネットワーク印刷に関するInternet Engineering Task Force (IETF)標準である。 この機能の多くはWebブラウザー(CUPS印刷サーバーにアクセスするプラットフォーム非依存の アクセスを提供する)経由でリモート(またはローカル)から管理することが出来る。さらに 追加で、伝統的なコマンド行といくつかのより新しいGUIインタフェースを持っている (GUIインタフェースはサードパーティによって開発され、たとえば、KDEのoverwhelming KDEPrintなどである)。
CUPSは、smartプリンター(すなわち、CUPSがプリンターに対して要求 された時にファイル形式の変換を行う)と同じように、rawプリンター すなわち、印刷ファイル形式を変換しない)の作成が出来る。多くの手段で、Microsoft Windows 印刷関しシステム同じような機能がCUPSにはある。もちろん、CUPSの推進者ならば、 CUPSの方がもっと良いと言うだろう!多くの場合、Samba経由でMicrosoft Windows印刷 クライアントとの間でCUPSがインタフェースを取るための設定方法を説明しよう。
Samba-3.0(2.2.xから使える)でのCUPSを使った印刷環境の、最も基本的なsmb.conf
のセットアップは
printing = cupsと
printcap = cupsという2つのパラメーターを必要とする。
CUPSはprintcapファイルを必要としない。しかし、cupsd.conf
設定ファイルは、
サードパーティアプリケーション(例えばPrintcap /etc/printcap
と
PrintcapFormat BSD
)に便利なように、どのように、CUPSによって
自動的に作成され、管理されるファイルを制御する2つの関連するディレクトリを知っている。
旧式のプログラムはしばしばprintcapファイルに含まれているプリンター名が存在することを
要求するので、そうでないと印刷を拒否してしまう。CUPSがprintcapファイルを作成して管理する
ようにしておくこと。詳細は、man cupsd.conf
と、
CUPS
Webサイトにある、CUPSサーバーそれ自身が提供する、関連する貴重な文書のようなCUPS関連の
文書を参照のこと。
SambaはCUPSと特別な関係がある。SambaはCUPSライブラリサポート機能を有効にして
コンパイルできる。最も最新のバージョンでは、このサポートを有効にしている。
既定値では、CUPSはsmbdとその他のSambaバイナリにリンクされる。もちろん、
libcups.so
をSambaにリンクしなくてもCUPSを使う事が
できるが、要求されるあるいはサポートされる設定にいくつかの違いがある。
Sambaがlibcups
とリンクされ、コンパイルされた時、
printcap = cupsは、プリンター一覧の表示、
ジョブの投稿、キューの問い合わせなどにCUPS APIを使う。それ以外は、印刷のために、
これらの操作を、-oraw
オプションを付加して、System Vの
コマンドにマップする。Linuxシステムでは、smbdが、libcupsライブラリにリンク
されているかを、ldd
ユーティリティを使う事で知ることが出来る
(ldd
は他のOSプラットフォーム上には無いかもしれないか、
その機能は別のコマンドによって行われるかもしれない):
root#
ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000) libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) [....]
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
行は、このバージョンのSambaがCUPSサポートするようにコンパイルされていることを
示している。もしもこの場合で、printing = cupsが設定されている場合、
他のsmb.conf
中にある、手動で設定した印刷関係のコマンドは無視される。
これは重要な点なので覚えておくこと!
何らかの理由で、固有の印刷コマンドを設定するために、 printing = sysvを設定することにより、これを行える ようにする事が必要である。しかし、CUPSとSambaを密に統合する利便性のすべてを 失うことになる。これを行う場合、以下のように、印刷システムコマンドを手動で設定しなければ ならない。 (最も重要: print command; other commands are lppause command, lpresume command, lpq command, lprm command, queuepause command and queue resume command).
最も簡単な印刷関連のsmb.conf
ファイル
に、基本的なCUPSサポートを有効にする、最も簡単な印刷関連のsmb.conf
設定を
要約する:
これはCUPSに対する基本的な印刷設定に必要なもののすべてである。Windowsクライアント から投稿されたすべてのグラフィック、PDFとPostscriptファイルは印刷できる。 しかし、ほとんどのWindowsユーザーは、GUIアプリケーションを開かないで、印刷する ファイルの種類を送る方法を知らない。Windowsクライアントはインストールされた ローカルのプリンタードライバーを持つ傾向があり、GUIアプリケーションの印刷ボタンは、 プリンタードライバーを開始する。ユーザーは滅多にコマンド行からファイルを送らない。 UNIXクライアントとは違い、グラフィック、テキストあるいはPDFファイルを直接 スプーラに送らない。通常、アプリケーションのネイティブな形式と印刷データ ストリームの間でホックされた“printer driver”を使うGUI アプリケーションから排他的に印刷を行う。もしもバックエンドプリンターが Postscriptデバイスでない場合、印刷データストリームは“バイナリ”で、 対象のプリンターのみが対象である。この問題が引き起こすこととそれを防ぐことを 学ぶために、この先を読み続けること。
1台のプリンター用にグローバルなCUPS設定を上書きする例
は、smb.conf
用の、やや複雑な印刷関連設定である。これはすべてのプリンターに対して
一般的なCUPS印刷サポートを有効にするが、1台だけ設定が異なるプリンター共有を定義する。
Example 22.2. 1台のプリンター用にグローバルなCUPS設定を上書きする
この特別な共有は、テスト目的専用である。これは印刷ジョブをファイルに書かない。
これは、ジョブパラメーターをSambaが認識する/tmp/smbprn.log
ファイルに記録し、ジョブファイルを削除する。さらに、この共有の
printer adminは“kurt”で
(“@ntadmins”グループではなくて)、ゲストアクセスは許可されず、共有は
ネットワークコンピュータに公開されず(そのため、これが共有であることを知っておく
必要がある)、3つのホストのみからアクセスできる。その共有に対して、CUPSが起動し、
印刷ジョブ上で通信をすることを防ぐために、
printing = sysvと
printcap = lpstatを設定する必要がある。
すべての設定オプションを確認する前に、いくつかの点について明確にする。 ネットワーク印刷は、きちんと計画されて、正しくセットアップされている 必要がある。このことは頻繁には発生しない。旧来のシステムや 小さな業務用LAN環境では、しばしばデザインと良い保守が存在していない。
多くの小規模オフィスや家庭用ネットワークでは、計画がひどい、より大きな環境と 同じように、各クライアントがネットワークプリンターへ直接アクセス出来るように なっている。これは一般的には悪いアイデアである。他のクライアントのジョブが 印刷しているときに、あるクライアントのアクセスを頻繁にブロックしてしまう。 ジョブが終了するのを待っている間、最初のクライアントのアプリケーションは フリーズしてしまうかもしれない。同様に、数多くのジョブが印刷しているとき、 それぞれが異なったページをまぜこぜにしてしまうという苦情もしばしば聞く。 よりよいコンセプトは、プリントサーバーを使うことである。これは、すべてのジョブを 集中したシステムに一本化し、即時に反応し、複数の並列したクライアントから ジョブを受け取り、正しい順序でプリンターに転送する。
ほとんどの現代的に設定されたUNIX印刷サーバーは、本当に単純なセットアップを意味する、 SambaのWindowsクライアントのために振る舞う。それらの唯一の業務は、Sambaによって すべてのジョブが扱われる“直接”スプーリングを管理することである。 この試みは、Windowsクライアントが、印刷デバイスに送られる準備が出来た印刷ジョブ ファイルを準備することが期待されるということである。この場合、ネイティブな (ベンダが供給した)Windowsプリンタードライバーは、各、およびすべてのクライアントで、 対象デバイスのものをインストールする必要がある。
同様に現代的な、簡単な方法で、CUPS、SambaとWindowsクライアントを設定することは 可能である。CUPSプリンターが直接印刷モード状態で設定されているならば、完全に 印刷ジョブ(ファイル)を描画することは、Sambaクライアントの責任である。ファイルは プリンターに直接配信するのに適した形式で送られる必要がある。クライアントはこれを 行うために、ベンダが提供したドライバーを動作させる必要がある。この場合、CUPSは 何ら印刷ファイル形式変換を行わない。
可能な、最も簡単な印刷設定は、直接印刷(raw print-through)である。これは、 Windowsクライアントに物理的に結合されているようにプリンターをインストールする 事によって行える。次に、それをrawネットワーク印刷キューにリダイレクトする。 この手続きは、以下の手順によって行えるだろう:
Procedure 22.1. 直接CUPS印刷サポートのための設定手順
/etc/cups/mime.types
の、ファイルの最後あたりにある
下記の行のコメントを外す:
#application/octet-...
Webインタフェースを使ってrawプリンターを追加する。ブラウザーで
http://localhost:631
をクリックする。
Administrationに入り、プロンプトに従ってプリンターを追加する。
ドライバーをこれにインストールしてはならない。Rawを選択する。
Raw Queue
というキュー名を選択する。
smb.conf
ファイル中の[printers]
セクションに
use client driver = Yesを追加し、
[global]
セクション中に、
printing = CUPSと
printcap = CUPSを追加する。
ローカルプリンターのようにプリンターをインストールし、結果、印刷先が
LPT1:
となる。
local port
を作成する。例:
\\server\raw_q
。ここで、raw_q
という名前はCUPS環境中で印刷キューに割り当てた名前である。
Windowsクライアント上のプリンタードライバーは2つの機能的に異なった方法でインストール できる:
二番目の方法は、管理コストの削減と、偶然異なったバージョンのドライバーが使われる ことを防ぐのに、最初のものを使うよりも推奨される。
もしも最初のオプション(ドライバーはクライアントサイド上でインストールされる)を使う 場合、注意すべき設定が1つある:CUPSに対して、手の込んだ(バイナリ)ファイル形式 である“raw”印刷を許可するように設定する。rawモード印刷を動かす ための、正しい設定する必要があるCUPSファイルは以下の通り:
/etc/cups/mime.types
/etc/cups/mime.convs
両者はRAMモード操作を許可するためにコメントアウトしなければならないエントリ
(それぞれのファイルの最後の部分)を含む。/etc/cups/mime.types
中では下記の行が存在するようにする:
application/octet-stream
/etc/cups/mime.convs
では、この行が存在するようにする:
application/octet-stream application/vnd.cups-raw 0 -
もしも、2つのファイルが、Windowsクライアントからの印刷に対して正しく設定されて
いない場合、恐ろしいUnable to convert file 0
というメッセージが、が、CUPSのerror_log
ファイル中に現れる
だろう。
mime.convs
とmime.types
ファイルを
“raw”印刷を行うことだけを
許可するように編集する。
背景.
CUPSは、伝統的な印刷システムが既定値では印刷デバイスに手の込んだ(おそらく
バイナリ)のデータを、ユーザーに送ることを認めていないと比べて、より
セキュリティに気づいている印刷システムである。これは、プリンターに対して、
少なくとも大量の紙とインクを無駄にすることとなる、
“サービス不能”攻撃を引き起こす不正な使い方を簡単に行える。
“不明な”データはCUPSによって、
MIME type: application/octet-stream
とタグ付けられ、
プリンターに送ることを許可されない。既定値では、他の(既知の)MIMEタイプである
“raw”のみを送ることが出来る。“raw”を送ることは、
CUPSがそれらを変換せず、何もさわらないでプリンターに渡すことを意味する。
これが、ベンダドライバーをローカルにインストールしたWindowsクライアントによって 準備された“raw”ファイルをCUPS/Sambaの協調印刷で行うときに知っておく 必要があることのすべてである。もしもより詳細なCUPS/Samba印刷についての背景 情報について興味がないならば、この章の残りの部分を読み飛ばせばよいだろう。
この節では、プリンタードライバーをアップロードする、3つのなじみやすい方法に、 さらに新しいもの1つについて説明する。
もしも、MS-RPCタイプの印刷を使いたいならば、最初にSambaサーバー上に
([print$]
共有)ドライバーをアップロードしなければならない。
Sambaホスト上からプリンタードライバーを配信する方法(結果、Windowsクライアントは
“ポイントアンドプリント”経由でダウンロードしそれを利用できる)
についての議論は、この資料の
旧式の印刷 の章を参照のこと。
以下は、Sambaサーバー上にクライアントドライバーを準備するための3つの方法への
説明又は参照である:
これらの3つの方法は、CUPSに対して同じように適用される。
cupsaddsmb
ユーティリティは最新で、CUPSを使っている場合、
WindowsドライバーをSamba中に起き、提供するより便利な方法である。
cupsaddsmb
は、この章の後の方でより詳細に説明される。しかし、
まず初めにCUPSフィルタリングシステムを説明し、WindowsとUNIXの印刷アーキテクチャの
違いを比較する。
“dump”プリントサーバーをセットアップする方法は分かっているが、それは すなわち、プリントジョブを“raw”でスプールするサーバーは、印刷データを 変更しないということである。
よりか指向違法方でCUPSをセットアップする必要があるかもしれない。その理由は いろいろとある:
もしかしたら、あなたの上司は月次の印刷統計報告を希望しているだろう。 すなわち、どのプリンターがどのくらいページを印刷したか?、印刷における平均的な 時間ピークはどのくらいか?、どの部署がどのくらい印刷したか?
もしかしたらプリントquotaシステムを設定したかと聞かれるだろう: ユーザーが、一定期間内での制限より超えたジョブを印刷出来ないという。
もしかしたら以前のネットワーク印刷の設定はひどい状態で、 一から再構成しなければならないだろう。
もしかしたらNT“kernelモード”で動作するあまりデバッグ されていないプリンタードライバーに起因する“ブルースクリーン”を、とても たくさん体験しているだろう?
これらのゴールはraw印刷サーバーによっては成し遂げることが出来ない。それらの要求に auサーバーを構築するためには、最初にどのようにCUPSが動作するかと、どのように それらの機能を有効にするかを学ぶ必要がある。
以下では、WindowsとUNIX印刷環境における、いくつかの基本的なコンセプトの 比較をまず行い、次に、CUPSフィルタリングシステムについて、どのように動作するか、 どのように微調整できるかの説明を行う。
ネットワーク印刷は最も複雑でエラーが発生しがちであり、ユーザーや管理者が 遭遇しがちである日々の作業の1つである。これはすべてのOSプラットフォーム上で 真実であり、そうなる理由がある。
プリンターに任意のファイルフォーマットを送り込み、それが印刷されることを期待する ことはできない。ファイルフォーマット変換を行う必要がある。問題は、すべての メーカとプリンタータイプに共通の、共通標準印刷ファイルフォーマットがないという ことである。Postscript(Adobeの商標)とその拡張であるPCL(HPの商標)はページ記述言語 (PDL)として使われていることにより、ほぼ公式な“標準”として開発されて いる。しかし、多くのメーカは引き続き“固有のものを使っている” (それらの理由は、プリンター内蔵のPostscriptインタプリタの、受け入れられないような ライセンス費用などである)。
WindowsOSでは、フォーマット変換ジョブはプリンタードライバーによって行われる。 Microsoft Windows OSプラットフォーム上ではすべてのアプリケーションプログラマは、 それらの基盤となるOSそれ自身の一部分、あるいは一区画として、自由に使える 組み込みのAPI、グラフィカルデバイスインタフェース(GDI)を使える。このGDIコアは 絵、フォントと文書を画面上に描画するのと同様に 紙の上に(印刷)する、すべてのWindowsプログラムにある1つの 共通基盤として使える。そのため、プリンタードライバー開発者はよく定義されたGDI出力を 固有のドライバー入力として標準化できる。WYSIWYG(What You See Is What You Get)の 実現は、スクリーン上のグラフィックプリミティブが紙上の描画オブジェクトと同じ ようで、同じソースから来るために、相対的に容易である。このソース、すなわちGDIは、 しばしば拡張メタファイル(EMF)と呼ばれるファイルフォーマットを生成する。EMFは プリンタードライバーによって処理され、プリンター固有のファイルフォーマットに変換される。
Microsoft Windows中のGDI基盤に対して、Appleは紙と画面出力を、その(BSDUNIXベース なのだがご存じだろうか?)Mac OS XとDarwinオペレーティングシステムという 同じ基盤上に置くことを選んだ。Appleのコアグラフィックエンジン は、すべての表示作業にPDF派生のものを使う。
ローカルプリンターに対するWindowsの印刷中の例は、 ローカルWindows印刷を図示している。
UNIXとLinuxでは、OSカーネルかX(画面表示)サーバー中に、構築された、類似のレイヤは ない。すべてのアプリケーションはそれ自身でその印刷出力を作成することに責任が ある。幸い、大部分がPostscriptを使い、それを何らかの共通基盤としている。 また、悪いことに、同じ文書を画面上に表示することとどのようにそれを紙に 印刷するかを行う、非常にたくさんの(そして何ら共通項がない)方法がある。 これは、数10年前にさかのぼってみると、グラフィカルユーザーインタフェースのための UNIX 基盤とプロトコルを設計したX.orgの前身は、幾人かがその時点で要求したように、 “紙出力”についての責任を取るのを拒否し、それ自身を “画面表示のみ”に制限した(何年か後、“Xprint” プロジェクトが開発中で、Xのフレームワーク中に、PostscriptとPCLドライバーを含む 印刷サポートを構築することを試みたが、まだ完成していない)。この、余り好ましくない 遺産は、使用しているシステムの、種々の“font”ディレクトリ中で、今も 見ることができる。X表示用と印刷用に使うフォントが分かれている。
背景. Postscriptプログラミング言語はAdobeの“開発物”であるが、その仕様は 広範囲に公開されている。その能力は、その強力なグラフィカルオブジェクト (フォント、シェープ、パターン、行、曲線、と点)を記述する能力、その属性 (色、線の幅)とそれらを操作する(拡大縮小、変形、回転、移動)ことによっている。 その公開された仕様により、能力がある誰でも、固有のPostscriptインタプリタ実装を 作成でき、画面あるいは紙状にPostscriptファイルを表示するのに使える。 ほとんどのグラフィック出力デバイスは “ラスタイメージ”か “ピクセル”(ペンプロッタは特筆すべき例外)というコンセプトを基盤と している。もちろん、テキスト形式でPostscriptファイルを見ることもでき、 ラスタライザによって解釈されるに必要な言語命令であるPostscriptコードを読む ことも出来る。ラスタライザは、ビューワプログラムによって画面上で表示されるか、 プリンターによって印刷されるかする、ピクセルイメージを生成する。
UNIXは紙への印刷と画面上への表示についての共通基盤が欠けている。UNIXの、好ましく ない遺産にもかかわらず、自由に使えるPostscriptプリンターを持っている場合、基本的な 印刷はかなり簡単である。その理由は、それらのデバイスは、ラスタイメージプロセッサ (RIP)と呼ばれる内蔵PostScript言語“インタプリタ”を持っているという (それにより、他のタイプのプリンターよりも値段が高い)ことである。それに向けて PostScriptを送り込むと、印刷したページを出力する。RIPは紙の上で見る事ができる、 ビットマップの絵にPostScript描画コマンドを変換するすべての大変な仕事をこなし、 プリンターによってそれを処理してしまう。これは、Windows上からPostScript印刷を 行うのと何ら違いはない。
一般的なUNIXプログラムと印刷システムが、PostScriptを使っている間は、主にPPDを 認識していない。PPDは“PostScriptプリンター記述”ファイルである。これは プリンターがサポートしているすべてのオプションを指定し、制御する事を可能にする。 そのオプションとは、たとえば、両面印刷、ステープル留めと穴空けである。そのため、 WindowsかAppleユーザーとは違って、たくさんのサポートされたデバイスとジョブ オプションを、UNIXユーザーは長い時間選択できなかった。しかし、今では、CUPSがある。 PostScriptプリンターによる印刷で図示されているように。
しかしながら、それ以外のタイプのプリンターもある。それらはどのようにPostscriptを 印刷するかが分からない。それらは、しばしばメーカ固有のPDLを使う。それらに対して 印刷を行う事の注文はもっと多い。利用しているUNIXアプリケーションはほとんどの 場合、Postscriptを生成し、それらのデバイスはPostscriptを理解しないので、 それに対してデータを送る前に、ホスト上で使用しているプリンターに合わせた印刷 ファイルのフォーマット変換を行う必要がある。
ここからGhostscriptの説明を始める。Ghostscriptは、UNIXプラットフォームで 使われている、伝統的な(そしてとても強力な)Postscriptインタプリタである。 これはソフトウェアによるRIPであり、ソフトウェアファイルフォーマットと同様、 非常に広範囲のハードウェアデバイスへの、たくさんのファイル変換を行う能力がある。 Ghostscript技術とドライバーは非PostscriptハードウェアでPostscript印刷を実行 できるようにするものである。これについては 非Postscriptプリンターに対するRIPとしてのGhostscript に説明がある。
使用しているGhostscriptバージョンの内蔵“デバイス”すべてを確認する
ために、“gs -h”コマンドを使う。もしも、使用しているGhostscriptの
コマンド行に-sDEVICE=png256
というパラメーターを指定した
ならば、入力をPNGファイルに変換するように、Ghostscriptに指定する。コマンド行上の
“device”の名前指定は、入力をどのように描画するかを正確に
Ghostscriptに指示するのに最も重要な単一パラメーターである。新しいGhostscriptの
バージョンは、現在artofcode LCCにおいて、通常かなり間隔を空けてリリースされる。
通常最初は“AFPL”ライセンスで提供されるが、次のAFPLバージョンが
リリースされると、すぐにGNU GPLライセンスで再リリースされる。GNU Ghostscript
はおそらくほとんどのSambaシステム上にインストールされているバージョンである。
しかし、いくつかの違いがある。
そのため、ESP Ghostscriptは、たくさんのバグ修正、追加のデバイスと改善がある、
GNU Ghostscriptの拡張として開発されている。これは、CUPS, Gutenprint, MandrakeSoft,
SuSE, Red Hatと Debianからの開発者によって一緒に保守されている。それには
“cups”デバイス(CUPSから非PSプリンターに印刷する基本部分)を含む。
Postscriptの本質がデバイス非依存の方式でページレイアウトを表現するための PDLである間は、実世界での印刷上部は常時デバイス固有の機能を持ったハードウェア 上で最終的に出力される。ハードウェアの違いに気を遣うことと、機能改善を図るため、 Adobeは文法とPostscriptプリンター定義(PPD)ファイルのファイルフォーマットを定義 してきた。すべてのPostscriptプリンターはそれらのファイルの1つを同梱して出荷されて いる。
PPDは、そのプリンターに割り当てられた一般的および特別な機能についてのすべての情報を 含んでいる。扱える異なった解像度は何か?両面印刷ユニットがあるか?ペーパートレイは いくつあるか?メディアのタイプとサイズは何が使えるか?それぞれの要素について、 プリンターに送られる特別なコマンド文字列を、それを有効にするために指定する事が 出来る(ほとんどの場合、Postscriptファイル中に)。
PPDからの情報はプリンタードライバーによって考慮されることを意味する。そのため、 与えられたプリンターのための、Windows PostScriptドライバーの一部としてインストール されるものはプリンターのPPDである。それが意味をなす場合、PPD機能は、印刷 オプションをユーザーに選択されるために表示される、ドライバーのユーザーインタフェース ダイアログ中で提供される。最後に、ユーザーの選択は、ドライバーによって作成された PostScriptファイル中に(特別なPostScript、PJL、JCLあるいはベンダ固有のコマンド 形式として)何らかの形で書かれる。
CUPSはそのPostScriptモデルのための、開発元によって供給された、すべての仕様に 従っているPPDを扱うことが出来る。もしもベンダがマニュアルとパンフレットに 使用しているOSについての言及がなかったとしても、それらを安全に信用できる: もしも、Windows NTバージョンのPPDを入手したならば、CUPS中で変更なしに利用でき、 その結果、Windows NTユーザーが出来るように使用するプリンターのすべての能力に アクセスできる。
オンラインでどのようなPPDの仕様遵守状態を確認するためには、 http://www.cups.org/testppd.php に行き、PPDをアップロードする。すぐにその結果を見ることができる。バージョン 1.1.19以降のすべてのバージョンのCUPSは、よりずっと厳しい内蔵PPD解析と検査 コードが有効になっている。印刷トラブルが起きたら、このオンラインリソースを 最初に調べる場所としてほしい。
CUPSフィルタリングシステムの中核は、Ghostscriptによっている。Ghostscriptを追加する事で、 CUPSはそれ自身固有のフィルタ以外のいくつかを使う。あなた自身(あるいはベンダ)はさらに フィルタを追加しても良い。CUPSはすべてのデータファイルフォーマットを種々のMIMEタイプの ラベル配下で取り扱う。入力された各印刷ファイルは、最初に行われる自動タイプわけに基づいて 扱われる。自動タイプわけにより、MIMEタイプが決定する。与えられたMIMEタイプは、選択された対象 プリンターに、0またはそれ以上の、フィルタリングチェーンが自動的に(暗黙のうちに)設定される。 この節では、どのようにMIMEタイプ認識と変換ルールが相互に作用するかについて説明する。 それらは、与えられた入力データフォーマットに対する、動作させるフィルタリングチェーンを 自動的に設定するために、CUPSによって使われる。
もしもCUPSがネイティブにビットマップにPostScriptファイルをラスタライズするならば、 それは以下の2つのステージで行われる:
使用するGhostscriptのバージョンが“cups”デバイスをコンパイルしてあるように
しておくこと(これはgs -h |grep cups
で調べられる。それ以外だと、
CUPS CUPS error_logファイルにUnable to convert file 0
というエラーメッセージが表示されるだろう。使用しているGhostscript中にデバイスとして
“cups”が含まれるようにするには、GNU Ghostscriptにパッチを当てて再コンパイル
するか、
ESP Ghostscriptを
使う必要がある。良い代替はESP Ghostscriptである。これはCUPSサポートだけではなく、
300もの他のデバイス(GNU Ghostscriptがおおよそ180くらいしかサポートしないのに対して)を
サポートする。この広範囲なデバイスサポートがあるという理由で、ESC Ghostscriptは
非CUPSスプーラ用の、最初の選択肢としても使える。すべてのスプーラに対して、
Linuxprinting.orgによって現在は推奨されている。
CUPSプリンターは外部レンダリングパスを使うように設定しても良い。最も共通的なものは、 Linuxprinting.orgからの Foomatic/cupsomaticコンセプトによって提供されるものである。これは古いGhostscript を用いて、すべてを1ステップで処理する。これは“cups”デバイスを使わないが、 その他の多くを使う。しかし、Foomatic/cupsomaticの使用にもかかわらず、最も良い解と 広範囲のプリンターモデルのサポートはESC Ghostscriptによって提供される (Foomatic/cupsomaticについての詳細、現在foomatic-ripと 呼ばれている、特に新しいバージョンについては、以下を参照)。
CUPSは/etc/cups/mime.types
(と、同じディレクトリ中にある、
すべての*.types
ファイル)を起動時に読み込む。これらの
ファイルはCUPSがそのautotyping機能を動かしているときに適用されるMIMEタイプ
認識ルールを含む。ルールの文法はmime.types
のマニュアル
ページとmime.types
ファイルそれ自身のコメントセクションに
記述されている。簡単なルールは以下の通りである:
application/pdf pdf string(0,%PDF)
これは、もしファイル名に.pdf
という拡張子が付いているか、
あるいは、マジック文字列%PDFがファイルそれ自身の先頭の
正しいところ(開始時点からオフセット0)にある場合、それはPDFファイルである
(application/pdf
)。その他のルールは以下の通り:
application/postscript ai eps ps string(0,%!) string(0,<04>%!)
もしも、ファイル名が.ai
, .eps
,
.ps
という拡張子のどれかを持つか、ファイルそれ自身が
%!か<04>%!という文字列の
どれかで始まるならば、それは一般的なPostScriptファイルである
(application/postscript
)。
CUPS中の2つの似たようなMIMEタイプとの間で、重要な違いがある。1つは
application/postscript
で、もう一つは
application/vnd.cups-postscript
である。
application/postscript
がデバイス非依存を意味するので、
ファイルのジョブオプションは引き続きPSファイルの内容の外側にあり、CUPSによって
コマンドラインか環境変数中に埋め込まれ、
application/vnd.cups-postscript
は、PostScriptそれ自身
中に埋め込まれるジョブオプションがあるかもしれない(適用可能ならば)。一般的な
PostScript(application/postscript
)の、デバイス固有の
バージョン(application/vnd.cups-postscript
)への変換は、
CUPSのpstops
フィルタの責任である。pstopsは変換を行う
ためにPPD中に含まれる情報を使う。
CUPSはASCIIテキスト,HP-GL, PDF, PostScript, DVIと多くの画像イメージ形式 (GIF, PNG, TIFF, JPEG, Photo-CD, SUN-Raster,PNM, PBM, SGI-RGBやその他)と それらに関連したMIMEタイプとそのフィルタを扱うことが出来る。
CUPSは/etc/cups/mime.convs
(と、同じディレクトリ中にある、
その他の*.convs
というファイルも)を起動時に読み込む。
それらのファイルには入力MIMEタイプ、出力MIMEタイプ、入力タイプから出力を生成
できるフォーマット変換フィルタとその変換に関連する仮想のコストを意味する行を
含む。その1つの例は以下のようになる:
application/pdf application/postscript 33 pdftops
これは、pdftops
フィルタが入力として
application/pdf
を取り、出力として
application/postscript
を生成する。この操作の仮想コストは
33 CUPS-$である。次のフィルタはより高価で、66 CUPS-$かかる:
application/vnd.hp-HPGL application/postscript 66 hpgltops
これは、HP-GLプロッタファイルをPostScriptへ変換処理する
hpgltops
である。
application/octet-stream
application/x-shell application/postscript 33 texttops text/plain application/postscript 33 texttops
最後の2つの例はapplication/x-shell
上と同じように
text/plain
で動作するtexttops
フィルタを意味する(ヒント:この違いは、texttops
の
特筆すべき機能の文法のために必要とされる)。
mime.convs
という名前の、よりたくさんの組み合わせがある。
しかし、あらかじめ定義してあるもの以外を使うことに制限はない。好みの、CUPS
フレームワークに対する任意のフィルタを追加できる。それは最小限の要求に適合
するか、させねばならない。もしも、ある種の効果的なフィルタを見つける(か書くか)
場合、CUPSの要求が要求するものに従い、適切な行をmime.types
と
mime.convs
に書く。そうするとCUPS内部でシームレスに動作する。
フィルタに対する“CUPSの要求”は単純である。入力としてファイル名か
標準入力
を取り、標準出力
に出力する。
これはまた下記の引数を持つ:
プリンターキューの名前(通常これは動かすフィルタの名前である)。
印刷するジョブのジョブID値(数字)。
オリジナルのユーザー名属性からの文字列。
ジョブ名属性からの文字列。
コピー数属性からの数値。
ジョブのオプション。
(オプション)印刷を要求するファイル(もしも指定されなければ、
フィルタは標準入力
からのデータ供給を
仮定する)。ほとんどの場合、CUPSで動作するようにさせるための
存在するフィルタを囲む単純なラッパプログラムを書くことは
簡単である。
以前に説明したように、PostScriptは、任意のUNIXベースの印刷システムにおいて 中核となるファイル形式である。PostScriptから、非PostScriptプリンターに送る ためのラスタデータを、CUPSは生成する。
しかし、印刷するためにサポートされた非PSフォーマットのどれかを送る時に何が起きる
のだろうか?次にCUPSはPostScriptを最初に生成するために、それらの入力上で
“prefilters”を動かす。これは、ASCIIテキスト,PDF, DVI,かHP-GLから
PostScriptを生成するためのprefilterである。それらのフィルタからの出力は常時
application/postscript
というMIMEタイプである
(これは任意のデバイス固有のオプションはCUPSによってまだPostScriptに埋め込まれて
おらず、呼ばれる次のフィルタはpstopsであることを意味する)。その出力は常時
application/vnd.cups-postscript
というMIMEタイプである
(application/postscriptではない)場合、プリントオプションはすでにファイルに
埋め込まれている事を意味する。これは、
PostScriptを整形するためのCUPS内のprefiltering
で説明されている。
pstopsは、application/postscript
を
application/vnd.cups-postscript
に変換するために使われる
フィルタである。以前に説明したように、このフィルタはすべてのデバイス固有の印刷
オプション(両面印刷やstanpingと穴あけなどをプリンターに指示するコマンド)を、
PostScriptファイル中に挿入する。その例は、
デバイス固有印刷オプションの追加に例示されている。
これがすべてではない。これにより行われるその他の処理は以下の通り:
印刷ページ範囲を指定する(すなわち、“3, 6, 8-11, 16と19-21” か、偶数ページのみ印刷することを選べる)。
1枚に2枚あるいはそれ以上のページを配置する(“数値-up” 機能と呼ばれる)。
/var/log/cups/page_log
に、
課金情報を記録するための、ジョブのページ数をカウントする。
pstoraster
はCUPSフィルタリングシステムの中核である。
これは、ラスタライズ処理の最初のステージに対して責任がある。その入力は
application/vnd.cups-postscriptというMIMEタイプである。その出力は、
application/vnd.cups-rasterである。この出力形式はまだ印刷可能にはなっていない。
その目的は、デバイス固有印刷データの生成を有効にする、より特殊化した
ラスタデバイスのための汎用入力形式として提供することである。
これについては、
PostScriptから中間ラスタ形式への変換ダイアグラム
を参照のこと。
CUPSラスタは強力な機能を持つ汎用ラスタフォーマットである。これは、ページ単位 情報、色のプロファイルなど、下位のラスタドライバーで使われるものを含むことが 出来る。そのMIMEタイプはIANAに登録されていてその仕様はもちろん完全に公開されて いる。それを作るのはとても簡単で、選択したものに対応すべきプリンターモデル用に、 LinuxとUNIXラスタドライバーを製造元が作成するために、費用がかからないように 設計されている。CUPSは常時ラスタライズする最初のステージに注意を払っているので、 ベンダはGhostscript互換について注意を払う必要はない(実際、CUPSラスタドライバーの 開発の資金調達を行っている、1つ以上のベンダが現在存在する)。これは、 Ghostscriptを使うCUPSラスタ生成の図解 に図示している。
バージョン1.1.15より前のCUPSバージョンでは、バイナリ(あるいはソースコードで)、
pstoraster
という名前の独立フィルタを提供していた。
pstoraster
はGNU Ghostscript 5.50由来で、代替インストール
可能で、競合なしにGNUあるいはAFPL Ghostscriptパッケージに追加される。
バージョン1.1.15以降、この機能は変更された。このフィルタの機能は、Ghostscriptに
統合された(現在はGNU Ghostscript バージョン 7.05をベースとしている)。
pstoraster
フィルタは現在-sDEVICE=cups
パラメーターを付けたgs
を呼び出す単純なシェルスクリプトである。
もしも、gs -h |grep cups
を実行したときにGhostscriptがエラーに
なるならば、印刷は出来ないので、Ghostscriptをアップデートする必要がある。
prefiltersについての節において、イメージ形式からPostScriptを生成するprefilter
について言及した。imagetoraster
フィルタは中間PostScript
ステージなしにイメージからラスタに直接変換するために使われる。これは以前に
言及したprefilterよりもより頻繁に使われる。イメージファイルのフィルタリングに
ついての要約フローチャートは
イメージ形式をCUPSラスタ形式に変換する流れである。
CUPSはCUPSラスタを処理するための非常に数多くのラスタドライバーを提供している。
筆者の環境では、/usr/lib/cups/filter/配下に
rastertoalps
,rastertobj
,
rastertoepson
,rastertoescp
,
rastertopcl
,rastertoturboprint
,
rastertoapdk
,rastertodymo
,
rastertoescp
, rastertohp
と
rastertoprinter
があった。これよりドライバーの数が少なくても
心配することはない。上記のいくつかはCUPSに対する商用アドオンであり
(rastertoturboprint
のような)、その他
(rastertoprinter
のような)は、可能な限りCUPSと協調する
ことを望んでいるサードパーティドライバー開発プロジェクトに由来する
(たとえばGutenprint)。
ラスタからプリンター固有形式への変換図
を参照。
CUPSフィルタリングチェーンについての最後の部分はバックエンドである。 バックエンドは、最終的なデバイスに印刷可能なファイルを送るための、特別な プログラムである。ネットワーク経由でと、すべてのローカルなインタフェースに 印刷ジョブを送るための、任意の異なった分離されたバックエンドプログラムが ある。すべてのCUPS印刷キューは、それに関連づけられているCUPS “device-URI”を持つ必要がある。device URIは、その送付先にジョブを 送るときに使われる、バックエンドをエンコードする方法である。以下で一覧表示 されているもので分かるように、ネットワークdevice URLは記述の中に2つの スラッシュ(斜線)を使い、ローカルdevice URLは1つのみを使う。ローカル インタフェース名は、OSがLinux以外の場合、筆者の例では非常に自由度があっても よいことを心にとめておくこと:
このバックエンドはUSB接続のプリンターに印刷ファイルを送る。使用する
CUPS device URIの例は以下の通り。
usb:/dev/usb/lp0
このバックエンドはシリアル接続したプリンターに印刷ファイルを送る。使用する
CUPS device URIの例は以下の通り。
serial:/dev/ttyS0?baud=11500
このバックエンドはパラレルポートに接続したプリンターに印刷ファイルを送る。使用する
CUPS device URIの例は以下の通り。
parallel:/dev/lp0
このバックエンドはSCSIインタフェースに接続されたプリンターに印刷ファイルを送る。使用する
CUPS device URIの例は以下の通り。
scsi:/dev/sr1
このバックエンドはLPR/LPDで接続されたネットワークプリンターに印刷ファイルを送る。使用する
CUPS device URIの例は以下の通り。
lpd://remote_host_name/remote_queue_name
このバックエンドはAppSocket(別名JetDirect)で接続されたネットワークプリンターに
印刷ファイルを送る。使用するCUPS device URIの例は以下の通り。
socket://10.11.12.13:9100
このバックエンドはIPPで接続されたネットワークプリンター(か他のCUPSサーバー)に
印刷ファイルを送る。使用するCUPS device URIの例は以下の通り。
ipp:://192.193.194.195/ipp
(多くのHPプリンター用)と
ipp://remote_cups_server/printers/remote_printer_name
このバックエンドはHTTPで接続されたプリンターにファイルを送る
(http:// CUPSバックエンドはipp://バックエンドの単なるシンボリックリンクである)。
CUPS device URIの例は以下の通り。
http:://192.193.194.195:631/ipp
(多くのHPプリンター用)と
http://remote_cups_server:631/printers/remote_printer_name
このバックエンドはWindowsホストによって共有されているプリンターに印刷ファイルを送る。 CUPS device URIの例は以下の通り。
smb://workgroup/server/printersharename |
smb://server/printersharename |
smb://username:password@workgroup/server/printersharename |
smb://username:password@server/printersharename |
The smb:// backendはSambaユーティリティsmbspool
(CUPSによって提供されていない)へのシンボリックリンクである。もしも
CUPSバックエンドディレクトリ中にシンボリックリンクがない場合、root
ユーザーになって、
ln -s `which smbspool' /usr/lib/cups/backend/smb
を実行してこれを作ること。
CUPS印刷システムに対して任意の変更又は拡張の必要性がある場合、シェル又はPerl スクリプトで固有のバックエンドを書くことは簡単である。印刷ジョブをメールとして (“mailto:/”バックエンド経由で)送る、PDFに変換する (“pdfgen:/”バックエンド経由で)、あるいは“/dev/null”に ダンプするというような“特別な”プリンターを作成したいというような 希望が理由としてあげられる(実際、システム全体での既定値のプリンターとして、 devnull:/バックエンドに接続するプリンターを用意している)。とても多くの人が、 プリンターを指定しないでジョブを送信したり、スクリプトとプログラムがプリンターを 指定しない。システム全体での既定値はジョブを削除し、$USERに、 正しいプリンター名を常時指定するようにという丁寧なメールを送る)。
説明したバックエンドすべて以外が使用しているシステム上にあるか、利用可能に
(ハードウェア設定に依存する)なっていてもよい。すべての有効なCUPSバックエンドを
調べる1つの方法はlpinfoとして提供されている。これを
-v
を付けて付こうと、すべての有効なバックエンドを下記のように
表示する:
$
lpinfo -v
cupsomatic
フィルタはCUPSをインストールするときに最も広く
使われているだろう。これらはCUPS開発者によって開発されたものではないということを
明確にする必要がある。これらはCUPSに対するサードパーティアドオンである。これらは
CUPSのためにジョブをレンダリングする従来のGhostscriptデバイスを使う。
問題が発生したときの調査時にはその違いを知っておく必要がある。ここでは1ステージで
すべてのレンダリングプロセスがGhostscript内部で、対象のプリンターに適したデバイスを
使って行われる。cupsomatic
は、Linuxprinting.orgにある
Foomaticプリンタードライバーデータベースから生成されたPPDを使う。
You can recognize these PPDs from the line calling the
cupsomatic
filter:
*cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
PPDファイルの最初の40かそのあたりで、この行を見つけるかもしれない。
もしも、そのような、インストールされたPPDがあるならば、プリンターは
foomatic
の名前部分にfoomatic
が
表示されたCUPS Webインタフェース中で表示される。
cupsomatic
は、選択されたPPDとプリントジョブに与えられた
コマンドラインオプションから自動的に構成された、すべての複雑なコマンドライン
オプションを付けたGhostscriptを実行させるPerlスクリプトである。
しかし、cupsomatic
は現在廃止されている。そのPPD(特に
最初に生成したものは、そこで引き続き頻繁に使用される)は、Adobeの仕様に適合して
いない。Windowsクライアントに“ポイントアンドプリント”でそれらを
ダウンロード仕様とするときに困難に遭遇するかもしれない。よりよい、かつ
強力な解決方法は現在提供されている。それは、foomatic-rip
と呼ばれる。CUPSでフィルタとしてfoomatic-rip
を使うために、
似たようだが異なった行を持つ、新しいタイプのPPDが必要である:
*cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
Linuxprinting.orgにあるPPD生成エンジンは修正された。新しいPPDはAdobeの仕様に
従っている。これらは異なった品質レベル(高解像度の写真、通常の色、グレースケールと
ドラフトモード)をシングルクリックで、5つまたはそれ以上の異なった選択(メディア
タイプ、解像度、インク種別とディザリングアルゴリズム)を要求できる新しい方法を
提供する。ビルトインされた固有のサイズのメディアサポートもある。ジョブの中間で、
ページ毎に印刷オプションを切り替えることのサポートもある。さらに、最もすばらしい
ことは、新しいfoomatic-rip
は、印刷時にPPDを使うための
アクセスに対するサポートを、すべての旧式なスプーラ(LPRng,BSD-LPD, PDQ, PPRなど)
に対してもシームレスに動作するということである。
CUPSは与えられたMIMEタイプとインストールされたすべてのプリンターに対する可能な すべてのフィルタリングチェーンパスを自動構築する。しかし、どのようにして 優先するものや特定の選択肢を決めるのであろうか(2つ以上の、同じターゲット プリンターに対するフィルタリングチェーンが存在するような場合があるだろう)? 簡単である。mime-convファイルの3番目のカラム中にある数字に気がついたかも しれない。それはこのフィルタに割り当てられている仮想コストを表現している。 すべての可能なフィルタリングチェーンは全体の“フィルタコスト” として集計される。CUPSは最も“コストの小さい”ルートを選ぶ。
CUPSに対して任意の“raw”ファイルを印刷(ほとんど)させることが出来る。
“raw”はフィルタされないことを意味する。CUPSは、プリンターがそれを理解
できる時に、思い悩まずに“そのまま”プリンターに対してファイルを送る。
ユーザーは賢明なデータ形式のみをそれらに送る事について注意を払う必要がある。raw
形式の印刷は、もしも“-o raw
”オプションが
コマンド行上で指定されたときにどのキューにおいても発生する。任意のPPDを単に関連
づけない事によってrawのみのキューを設定することも出来る。以下のように行う:
$
lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E
これは、“rawprinter”という“socket”プロトコル
(別名“HP JetDirect”)経由で接続してポート9100のIPアドレス
11.12.1.3.14のデバイスに接続するように設定する(もしもこのコマンド行に
-P /path/to/PPD
を付けたPPDを追加したならば、
“通常の”印刷キューとしてインストールされる。
CUPSは、もしもキューに関連づけられるPPDを見いだせない場合、自動的に各ジョブを “raw”と見なしてキューに送るように扱う。しかし、CUPSは既知の MIMEタイプ(CUPSが持つmime.typesファイルで定義されている)のみを送り、それ以外は 拒否する。
/etc/cups/mime.types
ファイル中にルールがない任意のMIME
タイプは、unknownかapplication/octet-stream
と
見なされ、送信されない。既定値で不明なMIMEタイプの印刷をCUPSが拒否するので、
Windowsクライアント由来の印刷ジョブが印刷されないということを経験するかも
しれない。以下のようなエラーメッセージがCUPSログファイル中に見つかるかもしれない:
Unable to convert file 0 to printable format for job
application/octet-stream
の印刷を有効にするためには、以下の
2つのファイルを編集する:
/etc/cups/mime.convs
/etc/cups/mime.types
両方ともapplication/octet-stream
のためのrawモード操作を
有効にするためにコメントアウトしなければならないエントリ(それぞれのファイルの
最後の所)を含む。下記の行が/etc/cups/mime.types
に存在する
ようにすること:
application/octet-stream
自動タイプルールセットが指定されていないこの行は、他の行で
application/octet-stream
のメンバーが自動タイプされていない
限り、全てのファイルを作成する。/etc/cups/mime.convs
中では
以下のような行になる:
application/octet-stream application/vnd.cups-raw 0 -
この行はCUPSに、application/octet-stream
上で
(“-”で示される、何もしない)Null Filter
を使うことを指示し、application/vnd.cups-raw
として
結果をタグづける。この最後の部分は、プリンターに接続しファイルを送信するための
バックエンドに向けてCUPSスケジューラがいつでも今あるファイルを引き渡せるように
している。
mime.convs
とmime.types
ファイルの編集は
“raw”印刷を強制せず、それを
許可するのみである。
Background.
そのCUPSは従来のものよりセキュリティに気を払っている印刷システムで、既定値では、
印刷デバイスに対して手の込んだ(おそらくバイナリ)データを送ることを誰にも許可して
いない(これは、使用しているプリンターに対してサービス不能攻撃をかける不正使用が
簡単にでき、少なくとも大量の紙とインクが無駄になることが発生する)。
“不明な”データはCUPSによって、MIMEタイプ
application/octet-streamと見なされる。
“raw”形式でデータを送ることができる場合、
それらのMIMEタイプは、CUPSとそれによって許可された、既知のもののどれかでなければ
ならない。/etc/cups/mime.types
というファイルはCUPSが
どのようにMIMEタイプを認識するかの“規則”を定義する。
/etc/cups/mime.convs
というファイルはどのファイル変換
フィルタがそのMIMEタイプに適用されるかを定義する。
オリジナルのPPDはPostScriptプリンターのみに使われることを意図していた。それらは ジョブファイルを処理する、RIPのためのデバイス固有のコマンドと設定を送るための 手助けとなる。CUPSはPPDに対するこのスコープを拡張し、非PostScriptプリンターにも カバーするようにした。これが標準化されたファイル形式のために、これを行うのは 難しくない。その方法は論理的でもある:CUPSはPostScriptを取り扱い、ジョブファイルを 処理するためにPostScript RIP(Ghostscript)を使う。唯一の違いはPostScriptプリンターは RIPを内蔵していて、その他のタイプのプリンターはホストコンピュータ上でGhostscript のRIPを動かすと言うことである。
非PostScriptプリンターに対するPPDはCUPS固有のいくつかの行を持っている。最も 重要なものは下記と似たようなものである:
*cupsFilter: application/vnd.cups-raster 66 rastertoprinter
これが CUPS フィルタリングの最後の難所のひとつである。この行では、CUPSデーモンに
対して、rastertoprinter
を最後のフィルタとして使うように
設定している。このフィルタは application/vnd.cups-raster
というMIMEタイプのファイルが入力の際に用いられることになる。CUPSは指定されたMIME
タイプを最終的な出力とするようなフィルタのチェインを自動的に生成する。
次にこれは指定されたrastertoprinter
フィルタのための入力と
なる。最後のフィルタが処理を終えた後(rastertoprinter
は
Gutenprintフィルタである)、ファイルは、出力デバイスに送信を行うバックエンドに
送られる。
CUPSが提供しているPPDは数少ないが、プリンターモデルは数多くある。異なった紙の トレイや指定されたモデルがサポートしているよりもより大きなマージンを取ることが 出来ないかもしれない。要約は表21.1“CUPSに同梱されているPPD”を参照。
Table 22.1. CUPSに同梱されているPPD
PPDファイル | プリンタータイプ |
---|---|
deskjet.ppd | 古いHP inkjetプリンターとその互換 |
deskjet2.ppd | 新しいHP inkjetプリンターとその互換 |
dymo.ppd | labelプリンター |
epson9.ppd | エプソン9-ピンインパクトプリンターとその互換 |
epson24.ppd | エプソン 24-ピンインパクトプリンターとその互換 |
okidata9.ppd | Okidata 9-ピンインパクトプリンターとその互換 |
okidat24.ppd | Okidata 24-ピンインパクトプリンターとその互換 |
stcolor.ppd | 古いエプソン Stylusカラープリンター |
stcolor2.ppd | 新しいエプソン Stylusカラープリンター |
stphoto.ppd | 古いエプソン Stylus Photoプリンター |
stphoto2.ppd | 新しいエプソン Stylus Photoプリンター |
laserjet.ppd | すべての PCL プリンター |
ネイティブなCUPSラスタライズ作業は2つのステップに分かれている:
しばしばこれは、その他の方法よりもより良い品質のものを生成する(そして、 いくつかのより優位な点がある)。これについては cupsomatic/foomaticの処理対ネイティブなCUPSの図 に図解がある。
1つの他の方法は、cupsomatic/foomatic-rip
によるものである。
cupsomatic
は、決してCUPS開発者によって
作られたものではないということに注意。これは、印刷環境に
対する独立した貢献であり、Linuxprinting.orgの人々によって作られたものである。
[6]
cupsomatic
はもはや開発、メンテナンス、サポートされいない。
これは現在 foomatic-rip
によって置き換えられている。
foomatic-rip
は古いcupsomatic
の
アイデアを完全に書き換えたものであるが、とても改善され、他の(非CUPS)スプーラに
対して汎用化されている。 foomatic-rip
へのアップグレードは、
特にもしも最新バージョンのCUPSにアップグレードするならば強く推奨される。
古いcupsomatic
のように、(新しい)Linuxprinting.orgが使う
現代的なGhostscript印刷処理からのfoomatic-rip
は、すべてを
単一のステップで行う。従ってそれはGhostscript中に組み込まれる他のすべての
デバイスに依存する。他のスプーラでのGhostscriptのレンダリングと同じくらい
品質は良い(あるいは悪い)。優位点は、この方法は、より最新のCUPSによる方法によって
(まだ)サポートされていない、たくさんのプリンターモデルをサポートするということで
ある。
もちろん、あるシステムで並列に両方の手法を使うことが出来(もしも異なったキューを 設定するならば1つのプリンターに対しても)、どれが一番うまく動作するかを見いだせる。
cupsomatic
は印刷ファイルを
application/vnd.cups-postscript
ステージ後に捕まえ、
システム全体でインストールされたGhostscriptである、CUPS-externalを通してそれを
横取りする。その結果、印刷ファイルはpstoraster
フィルタ
をバイパスする(さらにCUPSラスタドライバーrastertosomething
も
バイパスする)。Gostscriptがラスタライズ処理を終えた後、
cupsomatic
はレンダリングされたファイルディレクトリをCUPS
バックエンドに渡す。
cupsomatic/foomaticの処理対ネイティブなCUPS
にはネイティブなCUPSレンダリングとFoomatic/cupsomatic
手法の
違いについて図解している。
以下は、CUPSの動作を図解するための、よくあるフィルタリングチェインの例である。
HP JetDirect接続のPostScriptプリンターにPDFファイルを印刷しようとしていることを 仮定するが、ページ3-5,7と11-13のみを印刷したく、更にそれを“2アップ” と“両面印刷”にしたいとする:
使用する印刷オプション(要求されたページの選択、2アップ、両面印刷) は、コマンドライン上でCUPSに渡される。
(完全な)PDFファイルがCUPSに送られ、
application/pdf
として自動タイプされる。
その結果ファイルはPostScript MIMEタイプである
application/postscript
(ここでのプレビューは引き続き
オリジナルのPDFファイルのすべてのページを表示する)を生成する
pdftops
prefilterに、最初に渡さねばならない。
ファイルは次にコマンドラインオプションを適用する
pstops
フィルタに渡される:これはページ2-5,7と11-13を
選択し、“1枚のページ上に2つのページ”という合成されたレイアウトを
作成し、正しい“両面印刷”コマンド(プリンターのPPD中で定義されている)
を、新しいPostScriptファイルに挿入する。ファイルはこの時点でPostScript MIME
タイプapplication/vnd.cups-postscript
となる。
ファイルは、プリンターにジョブを転送する
ソケット
バックエンドに送られる。
フィルタリングチェーンの結果は以下の PDFからソケットへのチェーンの模式図のようになる。
CUPSstphoto2.ppd
をインストールした、USB接続の
Epson Stylus Photo Printerに同じフィルタで印刷したいと仮定しよう。最初の
いくつかのフィルタリングステージはおおよそ同じである:
印刷オプション(要求されたページの選択、2アップ、両面印刷)は、 コマンドラインでCUPSに渡される。
(完全な)PDFファイルはCUPSに送られて、
application/pdf
と自動タイプされる。
ファイルは、最初に、
PostScript MIMEタイプapplication/postscript
を
生成するpdftops
prefilterに渡されなければならない
(ここでのプレビューは引き続きオリジナルのPDFのすべてのページを表示する)。
ファイルは次にコマンドラインオプションを適用する“pstops”
フィルタに送られる。ここでページ2-5,7と11-13を選択し、
“一枚の紙の上に2ページを”合成し、正しい“両面印刷”
コマンド(おっと、このプリンターとPPDは両面印刷をサポートしていないので、
このオプションは無視される)を新しいPostScriptファイルに挿入する。
ファイルはこの時点でPostScript MIMEタイプ
application/vnd.cups-postscript
となる。
ファイルは次にpstoraster
ステージに送られ、MIME
タイプがapplication/cups-raster
となる。
最後に、rastertoepson
フィルタは、その処理を行い
(プリンターのPPD中で示されるように)、プリンター固有のラスタデータを生成し、
ユーザーが選択した任意の印刷オプションを、印刷データストリーム中に
埋め込む。
ファイルは、ジョブをプリンターに転送するusb
バックエンドに送られる。
フィルタリングチェーンの結果は PDFからUSBチェーンへの模式図のようになる。
インターネット上でたくさんのCUPS-PPDファイルを(それに適したフィルタと一緒に)、 たくさんの言語環境で、1000以上の非PostScriptモデル用をサポートしているものを 見つけることが出来る。
ESP PrintPro (商用、自由ではない)は、3000以上のPPDをパッケージしていて、 Linux, Mac OS X, IBM-AIX,HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital UNIXと他の商用UNIX上での“外部ドライバー”として使える (これは、CUPS開発者それ自身で書かれていて、その売り上げは 開発者を食べさせるという形で、将来のCUPS開発費用を助ける)。
Gutenprint Project (GPL、フリーソフトウェア)は140ほどのPPDを提供し(おおよそ400のプリンターを サポートしていて、多くは写真品質出力を提供する)、Gutenprint CUPS ドライバーと共に使われる。
TurboPrint (シェアウェア、自由ではない)は、とても良い品質で、おおよそ、プリンターの数と 同じくらいのサポートがある。
OMNI (LGPL、自由)は、IBMによって作られたパッケージで、現在400以上のプリンター サポートを含み、IBM OS/2のノウハウの遺産をLinux上に移植している (CUPSサポートは現在β状態である)。
HPIJS (BSD系のライセンス、自由) は、おおよそ150のHP製プリンターをサポートし、優れた印刷品質をも提供する (現在Foomaticパス経由でのみ有効)。
Foomatic/cupsomatic (LGPL、自由)は、Linuxprinting.orgからのもので、(Omni、GunenprintとHPIJS を含む)世界中に知られているほとんどすべての各Ghostscriptフィルタ用の PPDを提供する。
CUPSはまたSystemV AT&T印刷システムからとして知られている
“interface scripts”の使用もサポートしている。それらはしばしば
PCL印刷ジョブを生成するアプリケーションから、PCLプリンターにおいて使われる。
interface scriptsはプリンターモデルに特化している。これらはPostScriptプリンターの
ためのPPDと同様の役割を持っている。interface scriptsは、たとえば、もしも
ユーザーが特定のペーパートレイを選択したか、紙の方向を変更したかA3用紙を
しようするような場合、印刷データストリーム中に要求されたESCシーケンスを
追加してもよい。interface scriptsはLinux領域ではほとんど知られていない。
HP-UXプラットフォームでは、もう少し使われている。動作する任意の
interface scriptsをCUPS上で一緒に使うことも可能である。以下のように、
-i
を使ってインストールする:
root#
lpadmin -p pclprinter -v socket://11.12.13.14:9100 \ -i /path/to/interface-script
interface scriptsは多くの人にとって“未知の動物”かもしれない。 しかし、これは、CUPSと共に使うことで、ある特定の印刷キューに対する、固有の、 専用として記述した、フィルタリングスクリプトやプログラムを組み込む最も簡単な 方法を提供する(現代的なinterface scriptsの使い方に関するいくつかの情報は、 http://playground.sun.com/printing/documentation/interface.htmlにある)。
ネットワーク印刷は多くの分野をカバーしている。Windowsクライアントのために印刷するとき Samba上で何が起こるかを正確に理解するために、まず初めに、Windows NTサーバーと共に使う Windowsクライアントという、“Windowsのみ”の設定を見てみよう。
WindowsクライアントからNTベースの印刷サーバーへの印刷は、2つのオプションがある。 それらは以下の2つである:
ドライバーをローカルに実行し、GDI出力(EMF)を、使用している プリンターに対するプリンター固有の形式に描画する。
プリンター固有の出力に描画するためにドライバーが実行されたときに、 GDI出力(EMF)をサーバーに送る。
両方の印刷パスは クライアント上での印刷ドライバーの実行と サーバー上での印刷ドライバーの実行という フローチャートで図示されている。
最初の場合、印刷サーバーはraw形式でファイルをスプールせねばならない。これはジョブファイルに さわらず、何らの方法での変換もしないことを意味する。これは、現代的なUNIXベースの印刷 サーバーが同じように行えることでもあり、NT印刷サーバーよりもよりよいパフォーマンスとより 信頼性がある。これは、おそらくほとんどのSamba管理者が慣れ親しんでいるものである。この 設定の1つの利点は、この“スプールのみ”の印刷サーバーが、UNIX用のドライバーがない 場合にも使えるかもしれないと言うことである。これは、有効なWindowsクライアントドライバーが あり、クライアントにインストールされていれば十分である。これは クライアント上での印刷ドライバーの実行ダイアグラム で図示されている。
他のパスはサーバー上でプリンタードライバーを実行する。クライアントはサーバーにEMF形式で印刷 ファイルを送る。サーバーはPostScript, PCL, ESC/Pか他のドライバーを、EMFファイルをプリンター 固有の言語に変換するために使う。同じ事はUNIX上ではできない。現在、プリンターが理解できる ものに、UNIXサーバー上でWindowsクライアントのGDI出力を変換するプログラムか手法はない。 これはサーバー上での印刷ドライバーの実行ダイアグラムで 図示されている。
しかし、似たようなものはCUPSで可能なので、引き続き読むこと。
UNIX印刷サーバーがそのプラットフォーム上でWin32プログラムコードを 実行できないので、絵は若干異なる。しかしながら、 これは、それほど選択権を制限するものではない。それどころか、他では不可能な 印刷機能を実装することができるかもしれない。
Windowsネットワーク印刷クライアントに対する、CUPSの強力な機能の利点をどのように 利用するかを示す簡単なレシピである:
WindowsクライアントにPostScriptをCUPSサーバーに送らせる。
CUPSサーバーにPostScriptをドライバー固有のラスタフォーマットに変換させる。
これは、クライアントにPostScriptドライバー(プリンターが非PostScriptモデルであっても。CUPS サーバー上でのドライバーがあることも要求する)を使うことを要求する。
最初に、Samba経由でのCUPSベースの印刷を有効にするため、以下のオプションをsmb.conf
ファイルの[global]
セクションに設定すべきである:
printing = cups |
printcap = cups |
これらのパラメーターが指定されると、smb.conf
中の(Sambaそれ自身と同様)、すべての手動設定
した印刷ディレクティブ(たとえばprint commandか
lppause command)は無視される。その代わりSambaは、SambaがCUPS
ライブラリ(libcups)をサポートするようにコンパイルされているとき、CUPS APIを通してCUPSと
直接やりとりする。他の印刷コマンドが設定されていない場合、印刷は、-orawオプションを
自動的に付けてパススルーする、System VAT&Tコマンドセットを
使う(もし、コンパイル時にCUPSサポートをするようしたSambaサーバーで動作するよう、個別に
定義した印刷コマンドを使いたい場合、単に
classicalprinting = sysvを使う)。これは
CUPS/Sambaサーバー経由での印刷ダイアグラムで図示されている。
Sambaはそれ固有のスプールディレクトリ
(path = /var/spool/sambaに類似したもので設定される)
を、smb.conf
の[printers]
か[printername]
セクション中で使わなければならない。
Sambaは固有スプール空間にジョブを受け取り、CUPSのスプールディレクトリ(CUPSのスプール
ディレクトリは、既定値がRequestRoot /var/spool/cups
である、
RequestRoot
ディレクティブ行で設定される)中に渡す。
CUPSはそのスプールディレクトリのアクセス権限を検査し、毎回の再起動に備えて適切な値に
それをリセットする。
SambaとCUPSで共通のスプール空間を使う例は滅多に見たことがなく、何週間もこの
“問題”と苦闘してきた。
WindowsユーザーはSambaでのみ認証する(構成されるどんな手段でも)。もしもSambaがCUPSと同じ ホストで動作しているならば、印刷においては“localhost”のみ許可しなければ ならない。もしも異なったマシンで動作しているならば、CUPSで印刷できるように、Samba ホストがアクセス権を得られるようにしておかねばならない。
この節では、クライアントがCUPS-PPDと一緒にPostScriptドライバーを使うようにさせる、サーバーの 設定上でのCUPSフィルタの使い方について議論する。
PPDはすべての印刷デバイスオプションを制御できる。もしも、固有のPostScriptプリンターを 持っているならば、すなわちこれらは通常開発元によって提供される。PPDファイルは 、つねに、Microsoft WindowsまたはApple Mac OSシステム上でのPostScriptプリンタードライバーの コンポーネントである。それらはユーザーが選択できる印刷オプション、適切なPostScriptへの マッピング、対象プリンター用のPCLあるいはPJLコマンドを含むASCIIファイルである。プリンター ドライバーGUIダイアログはこれらのオプションを“その場で”ユーザーが選択できる、 ボタンとドロップダウンリストに変換する。
CUPSは、何らの変換なしに、任意のWindows(NTが推奨される)PostScriptドライバーからのPPD
ファイルロードでき、それらのオプションを扱える。印刷オプションのためのWebブラウザー
インタフェース
(http://localhost:631/printers/
を選択し、そこにある ボタンをクリック)か、
コマンドラインインタフェース(man lpoptions
か、システム上にあるならば、
lphelp
を参照)がある。これらはユーザーへのPPDオプションを提供出来る
Linux/UNIX上のGUIフロントエンドとは若干異なる。PPDオプションは通常、実際ののPostScript
プリンター上のPostScript RIPによって評価される事を意味する。
CUPSはそのPPDの使用にあたっては“実際の”PostScriptプリンターだけにに制限 されない。CUPS開発者は非PostScriptプリンターに対してもCUPS-PPDを使って有効なデバイスと ドライバーオプションを記述するPPDコンセプトの範囲を拡張した。
CUPSは完全なPostScriptインタプリタ(RIP)を含んでいるため、これは合理的である。RIPは
GhostScriptをベースにしている。これはクライアントからすべてのPostScript(と更に追加で、
その他のファイル形式)を受け取り処理できる。すべてのCUPS-PPDは、キーワード
*cupsFilter
で始まる追加の行を含んでいると非PostScriptプリンターに
ギアを切り替える。この行はCUPS印刷システムに、受け取ったPostScriptを解釈するための
プリンター固有のフィルタを使うように告げる。そのため、そのプリンターに対してPostScript RIP
として振る舞うことが出来るため、そのクライアントに対してPostScriptデバイスとしてその
すべてのプリンターを見せるようにし、受け取ったPostScriptコードを適切なラスタ印刷形式に
処理する。
Windowsクライアントでは“中核の”PostScript ドライバー に加えて CUPS-PPD も利用可能である。(ただし現在は CUPS PostScript Driver for Windows NT/200x/XP が推奨されている。これを使うと、制 限付きながら Adobe のドライバーが利用できる)。CUPS-PPD を使う場合、 他のスプーラではできない機能のいくつかを CUPS が利用できるよう になる。
統一した方法で、すべてのクライアントプラットフォームから、ネットワーク対応の 印刷ファイルを扱うPostScript RIPとして振る舞う。
すべてのファイルがpstopフィルタを通し、その結果page_log
に
記録されるため、CUPSの集中アカウント件請求サーバーとして振る舞う。
注意:これは、常時定義毎にフィルタなしが存在するため、
“raw”印刷ジョブでは該当しない。
たくさんの異なった対象プリンターがあっても、クライアントが、単一のPostScript ドライバーに集約することが出来るようになる。
Windowsクライアント上のCUPS PPDを使うと、すべての印刷ジョブ設定をUNIXクライアントが 出来るように制御する事が出来るようになる。
この設定は、WTS環境で大きな問題を体験している人にとって、特別な興味を引くかもしれない。 WTSはしばしば、そのクライアントの数多くのプリンターモデルを動かすために、多数の非PostScript プリンタードライバーをインストールする必要がある。これはしばしば非常に不安定性を増大させる。
“カーネルモード”で動作するWindows NTプリンタードライバーは、ドライバーが安定せず、 よくテストされていない場合には、システムの安定性にとって高いリスクとなる。そして、できの 悪いドライバーはたくさんあるのである!特に、悪名高いものは、ジョブの終了時にサウンドカード 経由でユーザーに通知を行う追加のサウンドモジュールが動くものを持っているPCLドライバーが例で ある。通常使っていて、“ブルースクリーン”をこれが出してしまうと言うことを言う 必要があるだろうか?
PostScriptドライバーは一般的によくテストされている。カーネルモードで動作したとしても、 それらが何かの問題を引き起こすことは知られていない。これは2つの異なったPostScript ドライバーが現在存在しているという事によるのかもしれない。1つはAdobeのものであり、もう1つは Microsoftのものである。両方ともよくテストされ、Windows上で想像できるように安定している。 CUPSドライバーはマイクロソフトのもの由来である。
回避方法として、サイト管理者は、WTS上にインストールされる許可されたドライバーを、1つの 汎用PCLと1つのPostScriptドライバーだけに制限するという方針を選んだ。しかしこれは、 クライアントが使う事が出来るたくさんの印刷オプションを制限することになる。 異なったドライバーによって制御される場合、そのデバイスはより良い動作が出来るはずが、 しばしば、1つの標準ペーパトレイでの単純な印刷よりも複雑なことが出来なくなる!
PostScriptドライバーを使い、CUPS-PPDを有効にすることは、すべてのこれらの欠点を解決する とてもエレガントな方法に見える。これらは使用するWindows OSバージョンに依存する、最大3つの 異なったドライバー、すなわちAdobe、MicrosoftとCUPS PostScriptドライバーが現在有効である。 WTS上で大きな安定性の問題を引き起こすことは、上記3つのどれも知られていない(たとえ、 たくさんの異なったPPDを使ったとしても)。クライアントは(再度)ペーパトレイ、両面印刷や その他の設定を選択できる。しかし、確かな代価もある:そのクライアントに対して、CUPSサーバーは PostScript RIPとして振る舞い、“raw スプール”デバイスとして振る舞うよりも よりCPUとメモリを必要とする。更に、この設定は、最初のフィードバックがとても有望ではあるが、 広範囲にはテストされていない。
より新しいW200xとに同梱されているXPプリンタードライバーでは、Windows NTとは異なり、カーネル モードでは動作しない。ただし、両OS共に、引き続き、カーネルモードで動作するドライバーを 使う事は可能である(端的に言って、サブディレクトリ“W32X86”中の “2”にあるドライバーが、“古い”ものかだと思って良いだろう)。 以前に説明したように、AdobeのものはMicrosoft PostScriptドライバーのように安定している。 CUPSドライバーはMicrosoftベースである。これは次のような理由による。Visual Studioの ライセンスを持つ人が無償で使える、Windows NT用のMicrosoftのDDK(Device Development Kit)は、 Microsoftがライセンスを持つドライバーのソースコードが含まれる。Visual Studioのライセンスを 持つ人は、自分が作るドライバーの開発作業に、そのコードを使用し、変更する事が許可されている。 CUPSではこのように開発されている。しかし、Microsoftのライセンスは、(DDKの部分を含む) ソースコード全体を公開することは許可していない。しかし、CUPSは、GPL配下で“差分”を リリースしている。そのため、もしも“MS DDK for Windows NT”のライセンスを 持っていれば、差分コードを使い、ドライバーを自分自身で調べる事が出来る。
前に説明したように、ダウンロードのためにSambaサーバー上でクライアントプリンタードライバーを 準備するためと、Windowsワークステーションの利便性のためのポイントアンドプリントのための、 すべての以前に知られている方法も、CUPS上で動作する。これらの方法は 旧式の印刷サポートで説明されている。実際は、 これは真のSambaビジネスで、Samba-Windowsクライアントの連携にのみ関連している。
cupsaddsmb
ユーティリティ(現在すべてのCUPSバージョンに同梱)は、
Sambaの[print$]
共有中に、プリンタードライバーを転送する別の解で
ある。思い出してほしいのは、この共有は、クライアントが、ドライバーが配布されると期待
し、ダウンロードとインストールのためにセットアップする場所であるということである。
これは、とても簡単に、任意の(か全部の)インストールされたCUPSプリンターの共有が出来るように
なる。cupsaddsmb
は、Adobe PostScriptドライバーを、最近開発された
Windows NT/200x/XP用のCUPS PostScriptドライバーと同様に使うことが出来る。
cupsaddsmb
は、ベンダプリンタードライバーと一緒に
動作することはできず、そのマニュアルページ中に名前がある
ドライバーと同じもののみ動作する。
CUPSプリンタードライバーはCUPSダウンロードサイトにある。そのパッケージ名は
cups-samba-[version].tar.gz
である。これには以下のような数多くの
利点があるので、Adobeドライバーよりも好まれる:
より正確なページ印刷情報をサポートする。
すべてのプリンターで、バナーページとページラベルをサポートする。
数多くのジョブのIPP属性の設定をサポートする (たとえば、ジョブの優先度、ページラベルとジョブの費用請求など)
しかし、現在Windows NT,2000とXPのみがCUPSドライバーによってサポートされている。もしも、 Windows95、98とMEクライアントのサポートが必要ならば、Adobe Driverのそれぞれの部分を 入手する事も必要である。
cupsaddsmb
を走らせる前に、
cupsaddsmb使用のためのsmb.conf
で示されるように、
smb.conf
を設定する必要がある。
Example 22.3. cupsaddsmb使用のためのsmb.conf
CUPSユーザーは
http://www.cups.org/software.html
から正確に同じパッケージを入手できる。これは、CUPSベースのソフトウェアファイルから
分離されたパッケージで、CUPS 1.1.x Windows NT/200x/XP Printer Driver for Samba (tar.gz,192k)
とタグづけられている。ダウンロードするファイル名はcups-samba-1.1.x.tar.gz
である。tar.gzファイルを解凍後、以下のファイルが展開される:
root#
tar xvzf cups-samba-1.1.19.tar.gz
cups-samba.install cups-samba.license cups-samba.readme cups-samba.remove cups-samba.ss
これらはESPメタパッケージャソフトウェアEPMでパッケージ化されている。
*.install
と*.remove
ファイルは簡単なシェル
スクリプトで、*.ss
のtarファイルを展開したものである
(*.ss
は、“tar”によって回答できる、tarアーカイブ
以外の何者でもない)。次に、これは内容物を/usr/share/cups/drivers/
に
置く。この内容物は以下のファイルを含む:
root#
tar tv cups-samba.ss
cupsdrvr.dll cupsui.dll cups.hlp
cups-samba.install
シェルスクリプトは簡単に扱える:
root#
./cups-samba.install
[....] Installing software... Updating file permissions... Running post-install commands... Installation is complete.
スクリプトは/usr/share/cups/drivers/
ディレクトリ中に
ドライバーファイルを自動的に置く:
root#
cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
バグのために、ある最近のCUPSリリースでは、cups.hlp
ドライバーファイルを
/usr/share/cups/drivers/
の代わりに
/usr/share/drivers/
中に置いてしまう。これを直すためには、
手動で正しい場所にファイルをコピー/移動する(./cups-samba.install
スクリプト実行後)。
この新しいCUPS PostScriptドライバーは現在バイナリのみである。しかし、無料で使える。 (まだ)完全なソースコードは提供されていない。その理由は、Microsoft DDKの手助けを得て Microsoft Visual Studio 6でコンパイルしつつ、開発されているからである。ドライバー開発者は フリーソフトウェアとしてソースコード全体を配布する許可を得ていない。しかし、CUPS開発者は GPL配下でソースコードの“差分”をリリースしているので、Visual StudioとDDK のライセンスを持つ人は誰でも自分自身でコンパイルすることが出来る。
CUPSドライバーは古いWindows 95/98/Meをサポートせず、Windows NT/2000/XPクライアントのみサポートする。
Windows NT, 2000と XPは以下でサポートされる:
cups.hlp
cupsdrvr.dll
cupsui.dll
古いWindows 95/98/MeのためのAdobeドライバーはWindows NT/2000/XPクライアントと 同じように提供されている。ファイルの組み合わせは異なったプラットフォームでは 異なる。
Windows 95, 98と MEは以下でサポートされる:
ADFONTS.MFM
ADOBEPS4.DRV
ADOBEPS4.HLP
DEFPRTR2.PPD
ICONLIB.DLL
PSMON.DLL
Windows NT, 2000, と XPは以下でサポートされる:
ADOBEPS5.DLL
ADOBEPSU.DLL
ADOBEPSU.HLP
Adobeドライバーファイルの入手は、多くのユーザーにとって予想外に難しいように見える。それらは
Adobe Webサイトに1つのファイルとして見えているわけではなく、自己解凍か自動インストールを
行うWindows-.exeファイルを見つけるのも難しい。おそらく内蔵されたネイティブな
インストーラを使用しなければならず、クライアント上で一回はインストールプロセスを動かす
ことが必要である。これは、クライアント上ローカルにドライバー(と1つの汎用PostScriptプリンター)
をインストールする。それらがインストールされた後、汎用PostScriptプリンターを共有する。
この作業後、クライアントの[print$]
共有は、CUPSホストから
smbclientで入手可能なAdobeファイルを保持する。
ESP Print ProソフトウェアのユーザーはAdobe PostScriptドライバーの代替として、ESCプリント
ドライバーパッケージをインストールすることが出来る。これを行うために、
Easy Software
Webサイトで、ESC Print Proソフトウェアの通常のダウンロード領域からドライバーファイルを
検索できる。Download Printer Drivers for ESP Print Pro 4.x
領域の間で“SAMBA”と名前が付いたリンクを探し、パッケージをダウンロード
する。一度インストールすると、Printer Manager GUI中の中のメニューの、
Export Driver...を選択して、プリンターを単にハイライトさせる
ことによって任意のドライバーを準備できる。もちろん、ドライバーファイルを扱うために、
あらかじめ準備されたSambaが必要である。すなわち、[print$]
共有を設定することなどである。ESP Print ProパッケージにはWindows 95/98/Me
クライアントファミリ用の(ライセンスされた)Adobeドライバー一式と同様にCUPSドライバー
ファイルが含まれている。
一度インストールスクリプト(と、/usr/share/cups/drivers/
への
cups.hlp
ファイルの手動での移動)を実行すると、ドライバーはSambaの
[print$]
共有(これはしばしば
/etc/samba/drivers/
にマップされ、WIN40と
W32X86という枝を持つサブディレクトリを含む)中に、ドライバーが
配置できるようになる。これは、cupsaddsmb
を動かすことによって
行える(CUPSリリース1.1.16以降ではman cupsaddsmb
も参照)。
smbpasswd
を動かしてrootをsmbpasswdファイル中に格納する必要が
あるかもしれない。もしも、全体の手順を最初に動かすときに、これは、特に重要であり、
Windowsドメインコンピュータでのシングルサインオン用にすべてが
設定されている環境中では動かない。
いったんドライバーファイルが[print$]
共有に置かれ、初期化
されると、それらはダウンロード可能になり、Windows NT/200x/XPクライアントによって
インストールされる。
Windows 9x/MeクライアントはCUPS PostScriptドライバーでは動かない。それらには
前述の通り、ADOBE*.*
ドライバーを使うことが引き続き必要である。
もしも、/usr/share/cups/drivers/
ディレクトリ中に以前の
インストールによるADOBE*.*
ドライバーファイルが引き続きあるならば、
それは無害である。
使用しているWindowsクライアントが、Adobe PostScriptドライバー用の古い
ADOBE*.*
ファイルがインストールされていると、新しい
Windows NT/200x/XP用のCUPS PostScriptドライバーのダウンロードとインストールは最初に失敗する。
最初にクライアントから古いドライバーを消し去る必要がある。もしも、プリンターを再インストール
しようとしたときのために、ドライバーファイルはクライアントによって引き続き保存され、
再利用されることによりプリンターを“削除”するだけでは十分ではない。
クライアント上のAdobeドライバーファイルを完全に取り除くためには、まず
プリンターフォルダーを開き(おそらく
スタート -> 設定 -> コントロールパネル ->プリンター)、
フォルダーの背景を右クリックし、ドライバータブを選択する。
一覧表示上で削除したいドライバーを選択し、削除ボタンをクリックする。
これは1つも特定のドライバーを使うプリンターが残っていないときに動作する。まず初めに
プリンターフォルダー中でこのドライバーを使うすべてのプリンターを
“削除”する必要がある。これを行うには管理者権限が必要である。
一度クライアントにCUPS PostScriptドライバーをダウンロードすると、
旧式の印刷サポートで説明したような手続きで、
すべてのプリンターを簡単に切り替えることが出来る。
プリンターのプロパティダイアログを動かすことか、
setdriver
サブコマンドを指定したrpcclient
を使うことのどちらかで、存在するプリンターのドライバーを切り替えられる。
CUPSとAdobe PostScriptドライバーの比較に興味があるだろうか?我々の目的のために、 Are you interested in a comparison between the CUPS and the Adobe PostScript drivers? For our purposes, these are the most important items that weigh in favor of CUPS:
Adobe EULAに縛られない。
“ADOBE*.*ドライバーファイルをダウンロードできる所はどこか?” という質問に縛られない。
Adobe ドライバー(sれに関連するプリンターのPPD要求において)はしばしば印刷ファイルの
メイン部分の先頭にPJLヘッダーを置く。そのため、印刷ファイルは
%!PS
の代わりに<1B>%-12345X
か
<escape>%-12345X
で始まる。これはCUPSデーモンが入力
ファイルを印刷可能なファイルと自動タイプすることをさせるようにし、
pstops
フィルタ経由で初期化しない(もう少し技術的に言うと、
これは一般的なMIMEタイプ
application/postscript
と見なされないが、より特別な
MIMEタイプである
application/cups.vnd-postscript
とみなす)ので、
/var/log/cups/page_log
中におけるページの計数は正確な
ページ数を受け取れない。その代わりに標準的な設定では、ダミーのページ数
“1”が記録される。
Adobeドライバーは、それによって生成するPostScriptを間違って 設定するいくつかのオプションがある (CUPSがそれを処理することが出来ないようにしてしまう、 Optimize for Speedを、 Optimize for Portabilityの代わりに、うっかりして 設定してしまう)。
WindowsクライアントによるCUPSサーバーへのCUPS PostScriptドライバーの
出力は、汎用MIMEタイプapplication/postscript
として
自動タイプされ、CUPS pstops
フィルタに渡され、会計と
quota目的のためにpage_log
中に正しいページ数を記録する。
CUPS PostScriptドライバーは、Windows NT/200x/XPクライアントによる、追加の標準(IPP) 印刷オプションを送信することをサポートする。そのような追加印刷オプションは、 CUPS標準バナーページ(かカスタムなもので、ドライバーは ダウンロード時点でインストールされるべき)と名前を付けられ、CUPSページラベル オプションを使い、ジョブのプライオリティを設定し、(将来、追加の便利な IPPジョブ属性をサポートするオプションで)印刷予定時間を設定する。
CUPS PostScriptドライバーは、PostScriptファイルの先頭に、新しい
*cupsJobTicket
コメントの挿入をサポートする
(これは、将来、すべての種類のCUPS上での便利な拡張のために使われるが、
これがコメントとして扱われ、単に無視されるため、任意の他の
アプリケーションのじゃまをしない)。
CUPS PostScriptドライバーは、近々リリースされる、 Windows NT/200x/XP用の完全なCUPS IPPクライアントの心臓部である (おそらく最初のCUPS 1.2のβリリースと一緒に)。
cupsaddsmb
コマンドは、必要とされるファイルを
[print$]
共有にコピーする。さらに追加で、このプリンターに関連
づけられているPPDは、/etc/cups/ppd/
から
[print$]
にコピーされる。これらファイルはポイントアンドプリント
経由でWindowsクライアントのインストールの都合のために待機している。コマンドを
正しく実行できる前に、Sambaに対して認証を行っておく必要がある。小さなネットワーク
環境では、おそらくユーザーレベルのセキュリティ
(security = user)を使っているだろう。
root#
cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via Samba:['secret']
すべてのプリンターとドライバーを共有するために、プリンター名の代わりに
-a
パラメーターを使う。cupsaddsmb
がプリンタードライバーを
Sambaに“エクスポート”してから、CUPSドライバーに関連づけられているキュー
のみ動作することは明白になるべきである。
おそらく何が起きているかを見たいのだと思う。より詳細な出力は、-v
パラメーターを使う。可読性向上のために下記の出力には手を入れてある。
すべての行末の“\”は手動で入れてあり、そのほかにインデントもしている:
root#
cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via GANDALF: Running command: smbclient //localhost/print\$ -N -U'root%secret' \ -c 'mkdir W32X86; \ put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \ put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \ put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \ put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp' added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows NT x86" \ "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \ RAW:NULL"' cmd = adddriver "Windows NT x86" \ "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \ RAW:NULL" Printer Driver infotec_2105 successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%secret' \ -c 'mkdir WIN40; \ put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \ put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM; \ put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \ put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \ put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \ put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \ put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;' added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL Running command: rpcclient localhost -N -U'root%secret' \ -c 'adddriver "Windows 4.0" \ "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \ PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:\ infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\ infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\ ICONLIB.DLL" Printer Driver infotec_2105 successfully installed. Running command: rpcclient localhost -N -U'root%secret' \ -c 'setdriver infotec_2105 infotec_2105' cmd = setdriver infotec_2105 infotec_2105 Successfully set infotec_2105 to driver infotec_2105.
出力結果上ではSambaアカウントのためのrootパスワードが表示されている。
もし、しっかり見た場合、ネットワーク上で暗号化されていないrootパスワードが転送されて
いることを発見するはずなので、注意するように。また、もしもさらによく見てみると、
出力中にNT_STATUS_OBJECT_NAME_COLLISIONというようなエラーメッセージを見つけるだろう。
これは、WIN40とW32X36というディレクトリが(以前のドライバーインストールにより)
すでに[print$]
というドライバーダウンロード共有中に存在
している時に発生する。これらは問題のないエラーメッセージである。
何が起きたのか?cupsaddsmb
は何をしたのか?手順には5つのステージがある:
ローカルのTEMPDIR中(cupsd.conf
で定義されている)に、
ファイルを一時的に格納する。
smbclient経由でSambaサーバーの[print$]
共有に
接続し、共有のWIN40(Windows 9x/Me用)とW32X86(Windows NT/200x/XP用)サブディレクトリ
中にファイルを書き込む。
1番目のリモートホストとしてSambaホストを、2番目のリモートホストとしてCUPSホストを指定する
ためのパラメーターを付けてcupsaddsmb
ユーティリティを実行できる。
特に、もしもより深く理解したい場合、何が起きたかをより明快にするためにテストしてみるのは
良いことである(実際には、ほとんどの人はCUPSとSambaサーバーを同じホストで動作させている):
root#
cupsaddsmb -H sambaserver -h cupsserver -v printer
もしもユーティリティがすべてのフィールドで正しく終わった場合、常時検査を しなければならない。少なくとも出力中の、以下の3つの メッセージをチェックする必要がある:
Printer Driver infotec_2105 successfully installed. # (for the W32X86 == Windows NT/200x/XP architecture).
Printer Driver infotec_2105 successfully installed. # (for the WIN40 == Windows 9x/Me architecture).
Successfully set [printerXPZ] to driver [printerXYZ].
これらのメッセージはおそらく一般的な出力中では簡単に認識できない。もしも
(ダウンロードのための、すべての有効なプリンタードライバーを
準備しようとする)-a
オプションを付けてcupsaddsmb
を
動かした場合、もしも個々のプリンタードライバーに、正しくにインストールすることに関して
問題がある場合、失敗するかもしれない。出力のリダイレクトは、結果を解析することを
手助けする。
もしも下記のメッセージが出た場合:
SetPrinter call failed! result was WERR_ACCESS_DENIED
これは、このプリンターに対してuse client driver = yes
という設定がされているかもしれないということを意味する。この設定を“no”に
すると、この問題が解決する。smb.conf
マニュアルページ中の、
use client driver
についての説明を参照のこと。
もしも、verboseモードでcupsaddsmb
を動かしていないと、何らかの診断
出力を得るのは不可能である。そのため、既定値であるquietモードを使わないことを強く
推奨する。quietモードを使うと、発生するかもしれない何らかの問題を隠してしまうだろう。
Samba PDC上で動かすために、標準のcupsaddsmb
コマンドは動かないのか?
認証のためにパスワードを繰り返し聞かれ、コマンドは全く起動しないのか?以下にある応用の
どれかを試してみてほしい:
root#
cupsaddsmb -U MIDEARTH\\root -v printername
root#
cupsaddsmb -H SAURON -U MIDEARTH\\root -v printername
root#
cupsaddsmb -H SAURON -U MIDEARTH\\root -h cups-server -v printername
(2つのバックスラッシュに注意:最初のものは二番目のものに対する“escape”である)。
cupsaddsmbフローチャートは、cupaddsmb
の
処理手順、コマンドフローとデータフローを示すチャートである。再度注意:cupsaddsmbは
raw印刷キューと一緒に動かないし、そういうことを意図してもいない!
cupsaddsmb
の完了後、ドライバーは、クライアントから使えるようになる。
以下は、ポイントアンドプリント経由でダウンロードしインストールするために行わなければ
ならない手順である。Windowsクライアントから、CUPS/Sambaサーバーをブラウズする:
数秒後、クライアントのローカルプリンター
フォルダー中に新しいプリンターが現れる。Windows XP上では、
Sambaサーバー上のプリンター名という名前が付けられている
(現在多くの場合kde-bitshop上のinfotec_2105のようになる)。もしもMicrosoft Wordのような
アプリケーションから、テストと最初のジョブを送りたい場合、有効なプリンター一覧の
ドロップダウンリスト中に、\\SambaServer\PrinterName
という
エントリで新しいプリンターが現れる。
cupsaddsmb
はCUPSバージョン1.1.15以上とSamba バージョン2.2.4以降でのみ
確実に動作する。もしも動かない場合か、クライアントへの自動プリンターダウンロードが成功
しないばあい、クライアント上でAdobe PostScriptドライバーのtop ofのCUPSプリンターPPDを手動で
インストールトーすすることができる。次に、UNCタイプの接続のために、クライアントの
プリンターキューをSambaプリンター共有に指定する:
cupsaddsmb
will only reliably work with CUPS version 1.1.15 or higher and with Samba
version 2.2.4, or later. If it does not work, or if the automatic printer driver download to the clients does
not succeed, you can still manually install the CUPS printer PPD on top of the Adobe PostScript driver on
clients. Then point the client's printer queue to the Samba printer share for a UNC type of connection:
C:\>
net use lpt1: \\sambaserver\printershare /user:ntadmin
これは、CUPSでネットワークされたPostScript RIP機能を使用することが出来るようになる (ユーザー“ntadmin”はプリンター共有にアクセスするための必要な権限を持つ 有効なSambaユーザーである必要がある)。これは、従来からのLanManによる方法(MS-RPCを使わない) でプリンターの接続を設定する。
印刷が動作するが、まだ問題があるとする。ほとんどのジョブは正しく印刷するが、いくつかは 全く印刷できない。いくつかのジョブは、とても良いとは見えないフォントの問題を抱えている。 いくつかのジョブは速やかに処理されるが、いくつかはとても遅い。これらの問題の多くは、 いくつかのガイドラインに従うことで、劇的に軽減できるか、完全になくなる。思い出して ほしいが、もしも使用している印刷デバイスがPostScriptが有効でない場合、 使用しているクライアントドライバーの設定が生成する出力を使って、CUPSホスト上での Ghostscriptインストールを取り扱ているはずである。以下のようにうまく処理するようにする:
Optimize for Speedという設定のPostScript出力オプションを抑制する。その代わりに Optimize for Portabilityを使用する(Adobe PostScriptドライバー)。
Page Independenceを使わない:設定なしにする。その代わりに、Page Independence: YES とする(CUPS PostScriptドライバー)。
推奨はTrue Typeフォントダウンロードオプション:Native True Type over Automatic and Outline である。なんとしてもBitmapを避けるべきである(Adobe PostScriptドライバー)。
True Typeフォントを選択する:Download as Softfont into Printer over the default Replace by Device Font (Adobeにおいては、各国のフォントは、出力を得るためにそれを戻す必要があるかもしれない。
時には、PostScript言語レベルを選択することが出来る:問題が発生した場合は 3のかわりに2を試してみる(Adobeにおいては、最新のESP Ghostscriptパッケージは レベル3のPostScriptをとてもうまく扱える)。
PostScriptエラーハンドラーにYesと答える(Adobe)。
もちろん、1つずつ、cupsaddsmbという便利なユーティリティ中に埋め込まれているすべての コマンドを動かすことと、アップロードと、将来のクライアントダウンロードのためにドライバー ファイルを準備することは出来る。
今これを行おうとしよう。最初に、最初の案を得るために、rpcclient
の
マニュアルを読む。印刷に関連するすべてのサブコマンドを見る:
enumprinters
,enumdrivers
,
enumports
, adddriver
と
setdriver
は最も興味があるものである。
rpcclient
はMS-RPCプロトコルの重要な一部を実装している。
これをWindows NT(か200x/XP)に問い合わせ(とコマンド)を行うのにも使える。MS-RPCは
Windowsクライアントによって使われ、とりわけ、ポイントアンドプリント機能に適合する
ために使われる。Sambaは今、同様にこれをまねることが出来る。
最初に、rpcclient
マニュアルページをチェックしよう。
個々には2つの読むべきな文節がある:
adddriver <arch> <config>
は、サーバー上でプリンタードライバー
情報をインストールするために、AddPrinterDriver()
RPCを実行する。
ドライバーファイルはgetdriverdir
によって返されるディレクトリ中に
すでに存在すべきである。arch
が取れる値は
getdriverdir
コマンドのものと同じである。config
パラメーターは以下のように定義される:
Long Printer Name:\ Driver File Name:\ Data File Name:\ Config File Name:\ Help File Name:\ Language Monitor Name:\ Default Data Type:\ Comma Separated list of Files
任意の空白のフィールドは“NULL”という文字列を入力すべきである。
Sambaはプリントモニターというコンセプトをサポートする必要がないので、通信のために双方向 リンクを使うことが出来るドライバーがあるローカルプリンターのためにのみそれらは適用される。 このフィールドは“NULL”にすべきである。リモートNT印刷サーバー上で、ドライバーに 対する印刷モニターはドライバーを追加する前にすでにインストールされていなければならない。 そうしないと、RPCは失敗する。
setdriver <printername> <drivername>
は、インストール
されたプリンターに関連するプリンタードライバーをアップロードするために、
SetPrinter()
コマンドを実行する。プリンタードライバーはプリンターサーバー
上にあらかじめ正しくインストールされている必要がある。
インストールされたプリンターとドライバーの一覧を得るための、
enumprinters
とenumdrivers
コマンドも
参照のこと。
正確なフォーマットはマニュアルページによって明快にはならないので、 空白を含むパラメーターを扱う必要がある。以下は、それに対するもう少しわかりやすい説明で ある。ここではコマンドを改行し、改行は“\”で示している。通常、改行なしに 1行でコマンドを記述するだろう: The exact format isn't made too clear by the man page, since you have to deal with some parameters containing spaces. Here is a better description for it. We have line-broken the command and indicated the breaks with “\”. Usually you would type the command in one line without the line breaks:
adddriver "Architecture" \ "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\ LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"
マニュアルページが示すものは、実際に存在する3つのコロンで分離されたフィールド中の、
単純な<config>
キーワードである。最後のフィールドは、
複数の(あまり尋常でない場合では、異なった20のもの)ファイルである。これは、最初は
混乱するように見えるかもしれない。“LongPrinterName”とマニュアルページが
呼んでいるものは、実際では“ドライバー名”と呼ばれるべきである。これは
自由に名前を付けられ、後でrpcclient ... setdriver
コマンド中で
この名前を使える。実用的な理由で、多くはプリンターと同じ名前をドライバーに付ける。
What the man pages denote as a simple <config>
keyword in reality consists of
eight colon-separated fields. The last field may take multiple (in some very insane cases, even 20 different
additional) files. This might sound confusing at first. What the man pages call the
“LongPrinterName” in reality should be called the “Driver Name”. You can name it
anything you want, as long as you use this name later in the rpcclient ... setdriver
command. For practical reasons, many name the driver the same as the printer.
これは全く単純ではない。“どのファイルがドライバーファイルをどうやったら分かるか”、
各“データファイル”, “構成ファイル”, “ヘルプファイル”
と“Language Monitorファイルの場合は?”という質問があるだろう。答えのために、
共有プリンターを持つWindows NTがそれらのファイルをどのように提供しているかを見てみるのも
よいかもしれない。覚えておいてほしいが、この全体の手続きはネットワーク上でWindows
コンピュータが発生させたトラフィックをモニターすることによってSambaチームにより開発
されねばならなかったと言うことである。Windowsマシンに切り替えて、UNIX
ワークステーションからうまくアクセスしても良い。それが何を送っているかを見るために、
rpcclient
で問い合わせてもよく、より明快にするために、マニュアル
ページの理解を試みても良い。
It isn't simple at all. I hear you asking: “How do I know which files are Driver File”,
“Data File”, “Config File”, “Help File” and “Language Monitor
File in each case?” For an answer, you may want to have a look at how a Windows NT box with a shared
printer presents the files to us. Remember that this whole procedure has to be developed by the Samba Team by
listening to the traffic caused by Windows computers on the wire. We may as well turn to a Windows box now and
access it from a UNIX workstation. We will query it with rpcclient
to see what it tells us
and try to understand the man page more clearly.
We could run rpcclient
with a getdriver
or a
getprinter
subcommand (in level 3 verbosity) against it. Just sit down at a UNIX or Linux
workstation with the Samba utilities installed, then type the following command:
root#
rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'
結果から、どれがどれであるか明快になるべきである。以下はインストールの例である:
root#
rpcclient -U'Danka%xxxx' W200xSERVER \ -c'getdriver "DANKA InfoStream Virtual Printer" 3'
cmd = getdriver "DANKA InfoStream Virtual Printer" 3 [Windows NT x86] Printer Driver Info 3: Version: [2] Driver Name: [DANKA InfoStream] Architecture: [Windows NT x86] Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL] Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD] Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL] Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP] Dependentfiles: [] Dependentfiles: [] Dependentfiles: [] Dependentfiles: [] Dependentfiles: [] Dependentfiles: [] Dependentfiles: [] Monitorname: [] Defaultdatatype: []
いくつかのプリンタードライバーはDependentfiles
というラベルで、
追加のファイルを一覧表示し、それらは最後のフィールドである
ListOfFiles,Comma-separated
中に押し込まれる。CUPS PostScript
ドライバー用には、それらは不要で(Adobe PostScriptドライバーも)、それゆえ、フィールドには
“NULL”が入るだろう。
Some printer drivers list additional files under the label Dependentfiles
, and these
would go into the last field ListOfFiles,Comma-separated
. For the CUPS PostScript
drivers, we do not need any (nor would we for the Adobe PostScript driver); therefore, the field will get a
“NULL” entry.
マニュアルページから(と上記のcupsaddsmb
の引用された出力から)、
手動でのアップロードとドライバーファイルの初期化を成功させるために、一定の状態を用意
する必要があることが明確になる。2つのrpcclient
サブコマンド
(adddriver
とsetdriver
)は、成功させるために、
以下の前提条件を準備する必要がある:
printer adminかroot(これはNTの
“Printer Operators”グループではないが、
smb.conf
の[global]
セクションで定義されている
printer adminグループ)で接続する。
要求されたドライバーを\\SAMBA\print$\w32x86
と\\SAMBA\print$\win40
に、適切にすべてコピーする。
これらは、その後最終的に“0”と“2”という
サブディレクトリで終わる。現時点では、それらをそこに
置いてはならない。それらは自動的に
adddriver
サブコマンドによって使われる(もしも共有中にドライバー
ファイルを置くために、smbclient
コマンドを使うならば、
“$”をエスケープする必要があることに注意。たとえば、
smbclient //sambaserver/print\$ -U root.
)。
Copy all required driver files to \\SAMBA\print$\w32x86
and
\\SAMBA\print$\win40
as appropriate. They will end up in the “0” respective
“2” subdirectories later. For now, do not put them there; they'll be
automatically used by the adddriver
subcommand. (If you use smbclient
to
put the driver files into the share, note that you need to escape the “$”: smbclient
//sambaserver/print\$ -U root.
)
接続しているユーザーは[print$]
共有に
書き込みとサブディレクトリの作成が出来ねばならない。
Windowsクライアント用に設定しようとしているプリンターは、 CUPSによってすでにインストールされている必要がある。
CUPSプリンターはSambaによって認識されねばならない:さもないと、
setdriver
サブコマンドは、NT_STATUS_UNSUCCESSFULというエラーで
失敗する。Sambaによってプリンターが認識されているかを調べるには、
rpcclient
でenumprinters
サブコマンドを
使うことが出来る。長く存在しているバグが、各smbdプロセスがSIGHUPを受け取るか、
再起動するまで、プリンター一覧の適切な更新を阻害している。ごく最近CUPSプリンターを
作成して問題が発生した場合、Sambaを再起動することを覚えておいてほしい。
すべての要求されたコマンドを実行して、手動で、プリンタードライバーをインストールしてみる。 最初、これは複雑なプロセスなように見えるという理由で、手順を1つずつ、やらなければ ならない、単一のアクションアイテム毎に説明する。 We are going to install a printer driver now by manually executing all required commands. Because this may seem a rather complicated process at first, we go through the procedure step by step, explaining every single action item as it comes up.
Procedure 22.2. 手動でのドライバーインストール
CUPS上でのプリンターのインストール
root#
lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E \ -P canonIR85.ppd
これは、CUPSシステムにmysmbtstprn
という名前のプリンターを
インストールする。プリンターはソケット(JetDirectかDirect TCP/IPとして知られる)
接続経由で接続される。このステップはrootで行う必要がある。
(オプション)Sambaによってプリンターが認識されているかを調べる。
root#
rpcclient -Uroot%xxxx -c 'enumprinters' localhost \ | grep -C2 mysmbtstprn
flags:[0x800000] name:[\\kde-bitshop\mysmbtstprn] description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn] comment:[mysmbtstprn]
これは、一覧中にプリンターを表示する。層でなければ、Sambaデーモン(smbd)をいったん 止めて再起動するか、HUPシグナルを送る:
root#
kill -HUP `pidof smbd`
再度チェックする。成功するまでトラブルシュートを繰り返し行う。
“description”行中に、2つのカンマの間に“空白”の
フィールドがあることに注意。すでに1つ存在していれば、ドライバー名はここに現れる。
このステップと、この後のステップのほとんどのために、rootのSambaでのパスワード
(smbpasswd
コマンドによって設定される)を知っておく必要がある。
代わりに、[print$]
に対してsmb.conf
中で
“write list”として定義されているユーザーからの1つで認証する事が出来る。
(オプション)プリンターに対するドライバーをSambaが認識しているかを調べる。
root#
rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2'\ localhost | grep driver
drivername:[]root#
rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' \ localhost | grep -C4 driv
servername:[\\kde-bitshop] printername:[\\kde-bitshop\mysmbtstprn] sharename:[mysmbtstprn] portname:[Samba Printer Port] drivername:[] comment:[mysmbtstprn] location:[] sepfile:[] printprocessor:[winprint]root#
rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
result was WERR_UNKNOWN_PRINTER_DRIVER
上記で示されている3つのコマンドのどれもドライバーを表示しない。 このステップはこの条件をデモンストレーションする目的で行われた。このステージにおける プリンターへの接続の試みは、 “The server does not have the required printer driver installed.” という行を表示する。
すべての要求されたドライバーファイルをSambaの[print$]に置く。
root#
smbclient //localhost/print\$ -U 'root%xxxx' \ -c 'cd W32X86; \ put /etc/cups/ppd/mysmbtstprn.ppd mysmbtstprn.PPD; \ put /usr/share/cups/drivers/cupsui.dll cupsui.dll; \ put /usr/share/cups/drivers/cupsdrvr.dll cupsdrvr.dll; \ put /usr/share/cups/drivers/cups.hlp cups.hlp'
(このコマンドは、単一の長い行で入力すべきである“\”によって示される
改行と行末は可読性向上のために挿入されている)。このステップは、次のものを成功
させるために必要とされる。これは、ドライバーファイルを物理的に
[print$]
共有中に存在させるようにする。しかし、それらを
Sambaはまだドライバーファイルとして扱えないので、クライアントはまだそれらをインストール
できない。クライアントがドライバーについて問い合わせると、引き続き
“not installed here”というメッセージが表示される。
現在どこにドライバーファイルがあるかを検査する。
root#
ls -l /etc/samba/drivers/W32X86/
total 669 drwxr-sr-x 2 root ntadmin 532 May 25 23:08 2 drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3 -rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp -rwxr--r-- 1 root ntadmin 278380 May 25 23:21 cupsdrvr.dll -rwxr--r-- 1 root ntadmin 215848 May 25 23:21 cupsui.dll -rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD
ドライバーファイルは現在[print$]
を“root”とする
W32X86アーキテクチャにある。
Sambaにそれらがドライバーファイルであると告げる(adddriver
)。
root#
rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \ "mydrivername:cupsdrvr.dll:mysmbtstprn.PPD: \ cupsui.dll:cups.hlp:NULL:RAW:NULL"' \ localhost
Printer Driver mydrivername successfully installed.
これが失敗してもこのステップを繰り返すことはできない。これは単なるtypoの結果であったと しても失敗する。それは、たいていの場合、ドライバーファイルの一部を“2” サブディレクトリ中に移動してしまっただろう。もしもこのステップが失敗したならば、 このステップを再度実行する前に、4番目のステップに戻り、繰り返す必要がある。この ステップ中で、ドライバーの名前を選択する必要がある。プリンターの名前として使うものと同じ 名前を使うことはよい方法である。しかし、大量にインストールする場合、明確に異なった 名前の、数多くのプリンターに対するドライバーを使っても良い。そのため、ドライバーの名前は 決定されない。
現在ドライバーファイルがどこにあるかを調べる。
root#
ls -l /etc/samba/drivers/W32X86/
total 1 drwxr-sr-x 2 root ntadmin 532 May 25 23:22 2 drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3root#
ls -l /etc/samba/drivers/W32X86/2
total 5039 [....] -rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp -rwxr--r-- 1 root ntadmin 278380 May 13 13:53 cupsdrvr.dll -rwxr--r-- 1 root ntadmin 215848 May 13 13:53 cupsui.dll -rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD
どのようにステップ6が適切なサブディレクトリ中にドライバーファイルを移動したかに注目。 ステップ5の後の状態と今の状態を比較する。
(オプション)Sambaが現時点でドライバーを認識しているかを確認する。
root#
rpcclient -Uroot%xxxx -c 'enumdrivers 3' \ localhost | grep -B2 -A5 mydrivername
Printer Driver Info 3: Version: [2] Driver Name: [mydrivername] Architecture: [Windows NT x86] Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll] Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD] Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll] Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
思い出してほしいが、このコマンドはステップ6で選択したドライバーの名前を検索する。 このコマンドは次のステップに行く前に成功しなければならない。
どのプリンターがこのドライバーファイルを使うかをSambaに告げる(setdriver
)。
root#
rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' \ localhost
Successfully set mysmbtstprn to driver mydrivername
任意のプリンター名(プリンターキュー)を任意のドライバーに結合できるので、これは同じドライバーを
使う数多くのキューを設定するのに便利な方法である。これを成功させるために、setdriver
コマンドに対する以前のステップのすべてを繰り返す必要はない。やらなければならない唯一の
準備は、enumdrivers
がドライバーを見つけられねばならないと言うことと、
enumprinters
がプリンターを見つけられねばならないと言うことである。
(オプション)この結合をSambaが認識しているかを調べる。
root#
rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ | grep driver
drivername:[mydrivername]root#
rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ | grep -C4 driv
servername:[\\kde-bitshop] printername:[\\kde-bitshop\mysmbtstprn] sharename:[mysmbtstprn] portname:[Done] drivername:[mydrivername] comment:[mysmbtstprn] location:[] sepfile:[] printprocessor:[winprint]root#
rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
[Windows NT x86] Printer Driver Info 3: Version: [2] Driver Name: [mydrivername] Architecture: [Windows NT x86] Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll] Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD] Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll] Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp] Monitorname: [] Defaultdatatype: [RAW] Monitorname: [] Defaultdatatype: [RAW]root#
rpcclient -Uroot%xxxx -c 'enumprinters' localhost \ | grep mysmbtstprn
name:[\\kde-bitshop\mysmbtstprn] description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn] comment:[mysmbtstprn]
ステップ2と3からの結果とこの結果を比較する。上記のコマンドの1つ1つはインストールされた
ドライバーを表示する。たとえenumprinters
コマンドが
“description”行上のドライバーを一覧表示するとしても。
(オプション)正しいデバイスモードにドライバーを修正する
クライアント上にドライバーをどのようにインストールするかについては確実に知っている はずである。特にWindowsに慣れていない場合、簡単なやり方がある: ネットワークコンピュータをブラウズし、Sambaサーバーを選び、共有を捜す。 すべての共有されたSambaプリンターが見えるはずである。質問(question)中の1つを ダブルクリックする。ドライバーが得られてインストールされて、ネットワーク接続が 設定される。別の方法は、プリンターとFAXフォルダーを開き、 質問(question)中のプリンターを右クリックし、接続又は インストールを選択する。その結果、クライアントのローカルの プリンターとFAXフォルダー中に新しいプリンターが現れ、それには Sambahostname上のprintersharenameのような何らかの名前が 付いている。
このステップをSambaのprinter admin(smb.conf
中で定義)として実行することは重要である。
これをWindows XP上で行う別の手法がある。これは、“DOSプロンプト”内で、
以下のようにコマンドラインを使う(要求された時に、rootのsmbpassordを入力する):
C:\>
runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry \ /in /n \\sambaserver\mysmbtstprn"
任意のプリンターの設定を一回変更し、 (縦方向を横方向になど) をクリックし、設定を元に戻す。
クライアント上でプリンターをインストールする(ポイントアンドプリント)。
C:\>
rundll32 printui.dll,PrintUIEntry /in /n "\\sambaserver\mysmbtstprn"
もしもこれが動かない場合、[print$]
共有のアクセス許可問題かもしれない。
(オプション)テストページを印刷する。
C:\>
rundll32 printui.dll,PrintUIEntry /p /n "\\sambaserver\mysmbtstprn"
次に5回[タブ]を入力し、[ENTER]を二回入力し、[TAB]を1回、そして再度[ENTER]を入力し プリンターの所に行く。
(推奨)テストページを調査する。
今は、プリンターのインストールについてすべてを知っていて、そこに書いてあることを読む必要は ない。額縁にこれを入れて、"初めてRPCCLIENTでインストールしたプリンター"というタイトルを 付けて壁に貼ろう。でも、やはり捨てるよね。 Hmmm. Just kidding! By now you know everything about printer installations and you do not need to read a word. Just put it in a frame and bolt it to the wall with the heading "MY FIRST RPCCLIENT-INSTALLED PRINTER" why not just throw it away!
(義務)飛び上がって成功を喜ぼう。
root#
echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd
もしもSambaが、キューがそこにないと考えた場合、setdriverコマンドは失敗する。 インストールが成功すると以下の頼もしいメッセージが表示される:
Printer Driver ABC successfully installed.
この後、adddriver
部分の手続きが続く。しかし、以下のような
期待はずれのメッセージが出るかもしれない:
result was NT_STATUS_UNSUCCESSFUL
CUPS中のキューを見ることができるだけでは十分ではないので、
lpstat -p ir85wm
コマンドを使う。最も最近のSambaのバージョンでは、
適切なキュー一覧の更新を妨害するというバグがある。Sambaを再起動するか、すべてのsmbd
プロセスにHUPを送るまで、新しくインストールしたCUPSプリンターの認識に失敗する。なぜSambaが
setdriver
コマンドを正しく実行しないかという理由がこれかと言うことを
検証するために、Sambaがプリンターを“認識している”かを調べる:
root#
rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm
printername:[ir85wm]
root#
rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm'
cmd = getprinter ir85wm flags:[0x800000] name:[\\transmeta\ir85wm] description:[\\transmeta\ir85wm,ir85wm,DPD] comment:[CUPS PostScript-Treiber for Windows NT/200x/XP]
所で、上記のコマンドに、さらにいくつかを使うことが出来、もちろん、 リモートのWindows NT印刷サーバーにもインストールできる!
すべてのSambaをインストールした環境にある、tdbという拡張子を持った、一連のファイル
は謎であろう。それらは、
connections.tdb
, printing.tdb
,
share_info.tdb
, ntdrivers.tdb
, unexpected.tdb
,
brlock.tdb
, locking.tdb
, ntforms.tdb
,
messages.tdb
, ntprinters.tdb
, sessionid.tdb
,
とsecrets.tdb
である。これらの目的はなんであるか?
Windows NT(印刷)サーバーは、Windowsレジストリ中にエントリを格納することによって、その
クライアントに対して、その作業を提供するのに必要なすべての情報を記録する。クライアントの
問い合わせはレジストリを読み取ることによって回答が行われ、Administratorかユーザーの
構成設定はレジストリ中に書き込むことで保存される。SambaとUNIXは明らかにこのような
レジストリを持っていない。Sambaはその代わりに、一連の*.tdb
ファイルに
すべてのクライアントに関連する情報を保存する(TDBはtrivial data baseの省略形である)。
これらはたいてい/var/lib/samba/
か
/var/lock/samba/
にある。印刷関連のファイルは、
ntprinters.tdb
, printing.tdb
,
ntforms.tdb
とntdrivers.tdb
である。
*.tdb
は人間に可読なファイルではない。それらはバイナリ形式である。
“なぜASCIIでないのか?”と質問するかもしれない。
“結局の所、ASCII設定ファイルは、便利でUNIXでの伝統である。”
Sambaチームによって、デザインがこうなった理由は、主に性能である。Sambaは高速で動作する
必要がある。ある環境では数千にもなる、各クライアントの接続毎に分離された
smbd
プロセスが動く。これらのいくつかは、
同じ時間に同じ*.tdb
ファイルをそれら
smbd
プロセスが書き込みアクセスをする必要があるかもしれない。
Sambaの*.tdb
ファイル形式は、これを提供できる。多くのsmbd
プロセスは同じ時間に同じ*.tdb
ファイルに書き込みができる。
これは純粋なASCIIファイルでは不可能である。
すべての*.tdb
ファイルはすべての読み取りと書き込みアクセス間で
整合性を保持することはとても重要である。しかし、これらのファイルが
壊れることがあるかもしれない(書き込み処理中に、
kill -9 `pidof smbd'
を実行すると、ダメージを与えることになる。
そのほか、急な電源断など)。このようなトラブルの場合、古い印刷関係の
*.tdb
ファイルを削除するのが唯一の解である。その後、その時点で
*.tdb
ファイルをバックアップから戻さない限り、すべての印刷関連の
設定を再作成する必要がある。
Sambaは、システム中にある*.tdb
ファイルをバックアップする、
rootユーザーを手助けする小さなユーティリティを同梱している。もしも引数なしでそれを
動かすと、以下のメッセージが表示される:
root#
tdbbackup
Usage: tdbbackup [options] <fname...> Version:3.0a -h this help message -s suffix set the backup suffix -v verify mode (restore if corrupt)
以下はprinting.tdb
ファイルをどのようにバックアップするかの例である:
root#
ls
. browse.dat locking.tdb ntdrivers.tdb printing.tdb .. share_info.tdb connections.tdb messages.tdb ntforms.tdb printing.tdbkp unexpected.tdb brlock.tdb gmon.out namelist.debug ntprinters.tdb sessionid.tdbroot#
tdbbackup -s .bak printing.tdb
printing.tdb : 135 recordsroot#
ls -l printing.tdb*
-rw------- 1 root root 40960 May 2 03:44 printing.tdb -rw------- 1 root root 40960 May 2 03:44 printing.tdb.bak
CUPSはHP LaserJetタイプのプリンターに対する良いサポートがある。以下のように汎用ドライバーを インストールできる:
root#
lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd
-m
スイッチは、CUPSが通常/usr/share/cups/model
中に格納する、まだインストールされていないPPDのための標準リポジトリから
laserjet.ppd
を検索する。代替として、
-P /path/to/your.ppd
を使っても良い。
しかし、汎用laserjet.ppd
は、各LaserJet五巻も出るの各特別な
オプションをサポートしない。すべてのモデルの、一連の“最小の共通項”が
構成要素である。もしもある理由で、商用のESP Print Pro ドライバーに対してお金を払わなければ
ならない場合、最初に見に行く所は、
Linuxprinting
Webサイト上にあるデータベースにすべきである。Linuxprinting.orgは、各プリンターに対して
使える最適のドライバーがどれか、ということについて、優れた推奨情報を提供している。
そのデータベースは、foomatic-rip
ユーティリティの主要な著者でもある、
MandrakesoftのTill Kamppeterの精力的な仕事によって、現在保持されている。
前者のcupsomatic
コンセプトは現在新しい優れたものにより置き換えられ、
より強力な foomatic-rip
が提供されている。
cupsomatic
はもはやメンテナンスされていない。新しいデータベースへの
URLは
Foomatic-3.0
である。もしもfoomatic-rip
にアップグレードする場合、Foomaticで制御
されるプリンター用の、新しい形式のPPDもアップグレードすることも忘れないこと。
foomatic-ripは古いcupsomatic
で生成したPPDでは動かない。新しい形式の
PPDはAdobe PPDの仕様と100%互換である。これらはまたSambaとcupsaddnmbユーティリティに
よってWindowsクライアントのためにドライバーを提供するために、代わりに使われる!
最近、ほとんどのLinuxディストリビューションは、(すべてのUNIXとMac OS XとDarwinでも動く) 印刷関連のソフトウェアを作成するために、 Linuxprinting.orgからのユーティリティに 頼っている。このサイトからのユーティリティは、サポートしているすべてのモデル、すべての スプーラ、すべてのOSとすべてのパッケージ形式(それらがないので)に対して、ドライバーとPPDの 簡単な更新が出来る、エンドユーザーにとてもわかりやすいインタフェースを持っている。その 歴史は、数年前にさかのぼる。
最近、Foomaticは、対応プリンターモデルが 1,000を超えるという 驚くべきマイルストーンに到達した。Linuxprinting.orgは、プリンタードライバー、サポートする モデルと、Foomatic データベース中で有効な種々のドライバー/プリンターの組み合わせに対するオプションについての、 すべての重要な要素を保持している。現在、そのデータベース中には、 245のドライバーが存在 する。多くのドライバーは種々のモデルをサポートし、多くのモデルは、異なったドライバーで 動作するかもしれない。これはあなたが選択するものである!
現在、690ものドライバーが完全に動作することが分かっている:181はほとんど 完全で、96は 部分的に完全で、46は文鎮(paperweight)である(???)。 これらの大半は、非PostScriptモデルであり(PostScriptプリンターは、CUPSによって、 固有の製造元が提供したWindows PPDを使うことによって、完璧にサポートされる)、多機能 デバイスは、GNU/Linux配下で、スキャンとコピーとFAXが出来ないならば、決して完全に 動くとは見なされないということを心にとめておいておくこと。これは本当に驚くべき 結果である!3年前、数は500以下であり、その時点でのLinuxかUNIX印刷は、現在の品質には 到達していなかった。 At present, there are 690 devices dubbed as working perfectly: 181 are mostly perfect, 96 are partially perfect, and 46 are paperweights. Keeping in mind that most of these are non-PostScript models (PostScript printers are automatically supported by CUPS to perfection by using their own manufacturer-provided Windows PPD), and that a multifunctional device never qualifies as working perfectly if it does not also scan and copy and fax under GNU/Linux then this is a truly astonishing achievement! Three years ago the number was not more than 500, and Linux or UNIX printing at the time wasn't anywhere near the quality it is today.
数年前、Grant Taylorが作業を開始した。 現在のLinuxprinting.orgの大元は、彼が書いた最初の Linux Printing HOWTO である。多数のLinuxユーザーと管理者に、この複雑で繊細な設定の最初のステップをガイドする ために提供された、この文書の関連プロジェクトとして(科学者にとって、印刷とは “紙の基盤の上に、インクかトナーの微片による明白なパターンによる構造化した堆積物を 付けたものである”)、その時点でのLinux印刷を補う、ハードウェアとドライバーについての 情報集積を行う小さなPostgresデータベースの構築を開始した。このデータベースは、現在に おける、Foomaticの、ツールとデータの集合体のコアコンポーネントになった。その途中で、データを XML表記に変更した。
“なぜこんな奇妙な名前なのか?”2000年の春頃に、これが軌道に乗ったときに、
CUPSは現在よりもかなり知名度が亡く、ほとんどのシステムはLPD、LPRng、か、あるいはPDQを
印刷に使用していた。CUPSはごくわずかの汎用ドライバー(100くらいの少数の異なったプリンター
モデルにのみ対応)しか提供できていなかった。デバイス固有のオプションのサポートも出来て
いなかった。CUPSは固有の組み込みラスタライズフィルタ(Ghostscript由来の
pstoraster
)も提供していた。他方、CUPSは、標準化され、きちんと
定義されているPPDファイルを使って、すべての印刷オプションの制御を
きちんとサポート出来た。さらに、CUPSは簡単に拡張できるように設計されていた。
Taylorはすでに、より多くのプリンターと、それと共に動くGhostscript“ドライバー”に ついて、良くできた動作状況一覧を、彼のデータベース中に用意していた。彼のアイデアは、 データベース情報からPPDを作成するためと、CUPSで動作する標準Ghostscriptドライバーを生成する ために、それがうまく動くことを検証することであった。また、それは一石数鳥でもあった:
これは、CUPSで有効な現在と将来のすべてのGhostscript フィルタ開発を行う。
CUPSユーザーにたくさんの追加プリンターモデルを有効にさせる (しばしば、伝統的なGhostscriptによる印刷は、1つのみが有効であるという理由で)
これは、Ghostscriptフィルタを使う事を望んでいる(あるいは 必要としている)ユーザーに、すべての詳細CUPSオプションを提供する(Web インタフェース、GUIドライバーの組み合わせで)
CUPSは cupsomatic という名前が付いた、簡単に作成されたフィルタスクリプトを経由して動作する。cupsomaticは Ghostscript経由でprintflieを動かし、必要とされる、どちらかというと複雑なコマンドラインを 自動的に構築する。これは、それが動くようにするために、CUPSシステム中にコピーされる必要が ある。cupsomatic制御がGhostscript病がプロセスを制御する方法を構築するために、CUPS-PPDが 必要である。このPPDはデータベースの内容から直接生成される。CUPSとそれぞれの プリンター/フィルタの組み合わせのために、CUPS-O-Maticという名前の、他のPerlスクリプトが PPDを生成する。これが動作した後、Taylorは2つの他のスプーラのために、類似のことを数日で 実装した。config-generatorスクリプトのために選ばれた名前は、(PDQ用には) PDQ-O-Matic と(推測したとおり、LPD用に) LPD-O-Matic であった。ここでの構成はPPDを使用しなかったが、他のスプーラ固有のファイルは使った。
その年の夏の終わり頃に、Till Kamppeterは 作業をデータベース中に格納し始めた。Kamppeterはその印刷システムをCUPSに変更するために、 新たにMandrakesoftに雇われ、その後 FLTKベースの XPP(CUPS lpコマンドに対するGUI フロントエンド)が出来た。彼は、大量の新しい情報と新しいプリンターを追加した。また、 PPR (ppromatic経由), GNUlpr,と LPRng (存在するlpdomatic経由両方)と スプーラなしの印刷 (directomatic) のような他のスプーラに対するサポートも開発した。
そのため、あなたの質問に答えるために、“Foomatic”は、 “*omatic”スクリプトに隠れたコードとデータをすべて上書きする汎用の 名前である。Foomaticは、バージョン2.0.xまで、CUPS用のLinuxprinting.orgのPPDに結合する (ひどい)Perlデータ構造を要求していた。異なったプリンター設定ファイルのように、すべての スプーラに対して異なった“*omatic”スクリプトがある。
これは、Foomatic バージョン 2.9(β)中と“安定版”3.0としてリリースされたもので すべて変更された。これは現在、すべての*omaticスクリプトの集合として到達して、さらにこれは foomatic-rip と呼ばれている。foomatcic-rip はすべての異なったスプーラと同様によって使われ、それがPPD (オリジナルPostScriptプリンターのPPDとLinuxprinting.orgが作成したもの両方)を読むことが 出来るという理由で、すべてのサポートされているスプーラは突然自由にPPDの機能を使えるように なる。ユーザーはシステムにfoomatic-ripを組み込む必要があるだけである。ユーザー用に、 改良されたメディア対湯とソースのサポートがある。それは、紙のサイズとトレイが簡単に設定 できるものである。
また、新しい世代のLinuxprinting.org PPDは、もはやPerlデータ構造を含まない。もしも、 あなたがディストリビューションメンテナで、以前のバージョンのFoomaticを使用している のであれば、..................しかし、 新しい foomatic-db-engine 経由で新しいバージョンのPPDセットを生成することを覚えておいてほしい! 個々のユーザーは、Foomaticチュートリアル中で概要が説明されている 以下のステップ か、この章によって、使用しているモデルのための、特定の、新しい単一PPDを生成することが 必要である。この新しい開発版は全く驚くべきものである。 Also, the new generation of Linuxprinting.org PPDs no longer contains Perl data structures. If you are a distro maintainer and have used the previous version of Foomatic, you may want to give the new one a spin, but remember to generate a new-version set of PPDs via the new foomatic-db-engine!. Individual users just need to generate a single new PPD specific to their model by following the steps outlined in the Foomatic tutorial or in this chapter. This new development is truly amazing.
foomatic-ripは、異なった文法、オプション、デバイスの選択、あるいは異なる各プリンター またはスプーラのためのフィルタを使うGhostscriptを動かすために必要な、とても巧妙な ラッパーである。同時に、これはプリントキューに関連づけられているPPDを読み、ユーザーの 選択に従って、印刷ジョブを変更する。これを一緒にすると、Adobeのspecに対し、新しい Foomatic PPDは100%準拠となる(ここ怪しい)。Foomaticのコンセプトにおける、いくつかの 革新的な特徴は、ユーザーを驚かせるだろう。これは、多くのプリンターに対する、個別の 紙サイズのサポートや同じジョブ内での、異なったペーパトレイを使う印刷のサポート ができる(両方の場合において、Windowsベースのベンダプリンタードライバーがこれをサポート していなかったとしても)。 foomatic-rip is a very clever wrapper around the need to run Ghostscript with a different syntax, options, device selections, and/or filters for each different printer or spooler. At the same time, it can read the PPD associated with a print queue and modify the print job according to the user selections. Together with this comes the 100% compliance of the new Foomatic PPDs with the Adobe spec. Some innovative features of the Foomatic concept may surprise users. It will support custom paper sizes for many printers and will support printing on media drawn from different paper trays within the same job (in both cases, even where there is no support for this from Windows-based vendor printer drivers).
ほとんどのドライバー開発それ自身は、Linuxprinting.org中では発生しない。ドライバーは独立した メンテナによって書かれる。Linuxprinting.orgはすべての情報を蓄え、そのデータベース中に 格納するだけである。さらに、今知られている、任意の最新式(あるいは旧来の)印刷システム 中にたくさんのドライバーを統合する、Foomaticという糊も提供する。
異なったドライバー開発グループについて話すと、仕事のほとんどは、それらのプロジェクトに おいて、現在ほとんど終わっている:
Omni IBMによるフリーソフトウェアプロジェクトで、良くできたOS/2時代のプリンター ドライバーの知識を、Linux/UNIXに対する、最新の、モジュラーなユニバーサルドライバー アーキテクチャに変換することを試みている(今だβ)。これは現在437モデルを サポートしている。
HPIJS HPによるフリーソフトウェアプロジェクトで、自分自身のモデルの領域における サポートを提供する(とても自然ではあるが、ほとんどの場合の印刷は、完璧なもので、 真の写真品質も提供している)。これは現在369モデルをサポートしている。
Gutenprint フリーソフトウェアの取り組みであり、(CUPSの主要開発者としても知られている) Michael Sweetによって開始され、現在驚異的な写真レベルの品質に到達した Robert Krawitzによって指揮されている(多くのエプソンユーザーは、その品質は、 Microsoftプラットフォーム向けのEpsonによって提供されたベンダドライバーよりも 良いと断言している)。現在522モデルをサポートしている。
Linuxprinting.orgは現在プリンタードライバーのダウンロードを行うためのとりまとめ窓口である。 プリンター情報を探し、 チュートリアル か、プリンターの問題について、よく知られている フォーラムで解決してみよう。 このフォーラムは、GNU/Linuxユーザーに限ったものではなく、 商用UNIXシステムの管理者も ここに来ていて、相対的に新しい Mac OS Xフォーラム は、ここ数週間で最も利用度の高いフォーラムの一つである。
Linuxprinting.orgとGhostscriptを囲むFoomaticドライバーラッパはすべての重要な ディストリビューション上で印刷のための標準ツール(tool-chain)である。それらのほとんどは、 基盤としてCUPSを使っている。ここ数年の間、ほとんどのプリンターに関するデータは、 Kamppeterによって追加され、多くの追加コードが、SuSE、Red Hat、Conectiva、Debianや その他の技術者から寄贈された。ベンダ中立はFoomaticプロジェクトの重要なゴールである。 MandrakeとConectivaは統合されて現在Mandrivaと呼ばれている。
MandrakesoftのTill Kamppeterは彼の空き時間にLinuxprinting.orgとFoomaticをメンテナンス するという優れた仕事を行っている。そのため、それをしばしば使うのであれば、 あなたが感謝しているという事を送ってほしい。
Foomaticデータベースはそれ自身だけで驚くべき工夫の1つである。プリンターとドライバー情報を
保存しているだけではなく、その内部XMLベースのデータベースから、その場でPPDファイルを
生成できる。それらPPDがAdobe仕様のPPDにモデル化される間、Linuxprinting.org/Foomatic-PPDは
普通ではPostScriptプリンターを制御できない。それらは、Eposn Stylus inkjet、HP Photosmart、
あるいは持っているプリンター上で鳴らすことや吹くことが出来る、すべてのベルと笛を
記述するのに使われる。その主要仕掛けは小さな追加の1行であり、PPDの仕様によって予測された
ものではなく、*cupsFilter
というキーワードで始まる。これはCUPS
デーモンに、どのようにPostScript印刷ファイルを処理するかを告げる(旧形式のFoomatic-PPDは
cupsomaticフィルタスクリプトと名前が付けられ、新しい形式のPPDはfoomatic-ripと呼ばれる)。
このフィルタスクリプトはホストシステム上でGhostscriptを呼び出し(推奨する別バージョンは
ESP Ghostscript)、レンダリング作業を行う。foomatic-ripは、
PostScriptジョブを、対象デバイス用のラスタフォーマットに変換する、Ghostscriptから
問い合わせを行う、フィルタか内部デバイス設定がどれかを知っている。この、
非PostScriptプリンターのオプションを記述するPPDの使用法は、CUPS開発者の発明である。
その結果は簡単である。GUIツール
(すばらしいKDEのkprinter
か、GNOMEのgtklp xppとCUPSのWebサイト)
はPPDを読み取り、その情報を直感的な面ふー選択として、ユーザーに対し、有効な設定を
提供するための情報として使う。
以下はfoomati-ripで制御される、CUPSでのLaserJet 4Plus互換プリンターインストール手順である
(SuSE、UnitedLinuxとMandrakeにおける最新ディストリビューションではFoomatic-PPDの完全な
パッケージとfoomatic-rip
ユーティリティを同梱している。
Linuxprinting.orgに直接行くと最新のドライバー/PPDファイルを入手できる)。
inuxprinting.orgのプリンター一覧ページ をブラウザーで開く。
データベース 中の完全なプリンター一覧をチェックする。
使用しているモデルを選択しそのリンクをクリックする。
このモデルに対して動作可能なすべてのドライバーの一覧ページが表示される (すべてのプリンターに、必ず1つ推奨ドライバーがある。まず初めにそれを試す)。
この例の場合(HP LaserJet 4 Plus)、 HP-LaserJet 4 Plus という既定値のドライバーになる。
推奨ドライバーはljet4である。
いくつかのリンクがここで提供されている。Linuxprinting.orgに 不慣れならば、それらすべてを見てみるべきである。
ljet4 に対するデータベースページへのリンクがある。ドライバーのページ上には、種々の有効な スプーラでそのドライバーをどのように使うかについての重要かつ詳細な情報がある。
他のリンクは、ドライバーの著者のホームページを示しているだろう。
CUPS に関するセットアップ手順のヒントを提供する重要なリンクがある: PDQ; LPD, LPRng, と GNUlpr); 同様にPPR または“spoolerless” printing.
このリンク経由でブラウザー中でPPDを閲覧できる: http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1
最も重要なことは、 PPD を生成しダウンロードできると言うことである。
PPDは使用するモデルとドライバーが使うときに必要なすべての情報を 含む。一度インストールすると、これはユーザーに対して透過的に動作する。その後は Webベースのメニューか、印刷ダイアログGUIか、コマンドラインから、解像度、 紙のサイズなどのみを指定する必要がある。
もしもドライバー ページ で作業を終わるならば、“PPD-O-Matic”オンラインPPDジェネレータ プログラムを使う選択が出来る。
正確なモデルを選択し、Downloadか Display PPD fileのどちらかをチェックし、 Generate PPD fileをクリックする。
もしもブラウザービューからPPDファイルをセーブした場合、 カットアンドペーストは使わないこと(行末やタブ情報を欠落する可能性があるため、 PPDファイルが壊れてしまう可能性が高くなる)。代わりに、 ブラウザーメニュー中のDownloadオプションを使うのが 最も良い)。
を 使う(Webページからの各ドライバーページ上にある、他の興味深い部分は、 “それを行うことでGhostscriptを学ぶ”優れた方法である。 また、忌々しい印刷スクリプトのための、優れたコマンドラインを再構築することを 必要とするすべての経験者のための、優れた一覧表(cheat sheet)でもある。 しかし、それは正確な文法を思い出すことはできない。
である。もしも使用している プリンターモデルを指定し、そのボタンをクリックすると、完全なGhostscript コマンドラインが表示され、そのドライバーとプリンターモデルの組み合わせに対して 有効なすべてのオプションをエミュレートする。これは時々、Linuxprinting.orgを見ている間に、ハードディスクの
/path/to/my-printer.ppd
のような、適当な位置にPPDを
セーブする(CUPS Webインタフェースの助けを借りて使用しているプリンターを
インストールすることを好むならば、PPDを
/usr/share/cups/model/
というパスにセーブし、
cupsdを再起動する)。
次に、以下のようなコマンドラインでプリンターをインストールする:
root#
lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \ -P path/to/my-printer.ppd
Linuxprinting.orgからの、新しい形式の“Foomatic-PPDs” 用には、foomatic-ripと呼ばれる特別なCUPSフィルタも必要である。
foomatic-rip Perlスクリプトそれ自身もいくつか興味深い 読み物 を作る。なぜならば、Kamppeterによるインラインコメントによってよく文書化されて いるからである(非Perlハッカーが、それを読むことで印刷について多少勉強できる)。
/usr/lib/cups/filter/foomatic-rip
か
他の$pathのどちらかにfoomatic-ripを保存する(そして、それを誰でも実行できる
ようにするのを忘れないこと)。繰り返すが、コピーアンドペーストでセーブしない
こと。適切なリンクを使うか、ブラウザー中の
保存を使うこと。
もしも固有の$PATHにfoomatic-ripを保存したならば、シンボリックリンクを作る:
root#
cd /usr/lib/cups/filter/ ; ln -s `which foomatic-rip'
CUPSはcupsdを再起動後起動時に有効なこの新しいフィルタを検索する。
一度Foomatic PPDで設定された印刷キューに印刷すると、CUPSは適切なコマンドを挿入し、 結果のPostScriptファイル中にコメントを挿入する。foomatic-ripはそれを読み、それらに 対して処理を行うことが出来、さらに、ジョブファイル中に埋め込まれている、特別にエンコード されたFoomaticコメントのいくつかを使う。それらは順に(ユーザーにとっては透過的に) どのように結果のラスタデータを見えるようにすべきかと、どのプリンターコマンドを、 データストリーム中に埋め込むかを、正確に、プリンタードライバーに指示する、複雑なGhostscript コマンドを組み立てるのに使われる。以下が必要である:
“foomatic+なにか” PPD しかし、 CUPSで印刷するためには、これだけでは不十分である(これは単に 1つの重要な要素である)。
/usr/lib/cups/filters/
中の
foomatic-rip
フィルタスクリプト(Perl)。
foomatic-ripを動かすためのPerl
使用しているプリンターが受け取れる形に適合したラスタデータを 生成するためのGhostscript(これが主要な仕事を行うため、PPD/foomatic-ripの組で 制御される)
Ghostscriptは(ドライバー/モデルに依存するが)使用しているモデルに
対する選択されたドライバーを表す特定のデバイスに対するサポートを
含んでいなければならない(gs -h
によって
確認できる)。
しばしば、日、週、月単位に、一定のページ数かデータ量を超えて、Sambaユーザー(すなわち Windowsクライアント)が、印刷が出来ないようにする、印刷quotaに関連する質問がある。 この機能は、使用している実際の印刷サブシステムに依存する。Sambaはクライアントから 常にジョブファイルを受け取り(フィルタされるか否か、この印刷 サブシステムに渡す。
もちろん、使用している人固有のスクリプトで、これをハックすることは出来る。しかし、 CUPSがある。CUPSは、ジョブのサイズやページ数やその両方をベースとできるquotaを サポートし、それを行いたいときにはいつでも橋渡しをすることが出来る。
CUPSで印刷quotaをrootがどのように設定するかのコマンド例であり、存在するプリンターが “quotaprinter”であることを仮定している:
root#
lpadmin -p quotaprinter -o job-quota-period=604800 \ -o job-k-limit=1024 -o job-page-limit=100
これは個々ののユーザーに対して、604800秒(=一週間)で、100ページまたはデータが1024KBでの 制限を行う(どちらか小さい方)。
CUPSで正しく計測するために、印刷ファイルはCUPSpstopsフィルタに送られる必要がある; そうでない場合、ダミーのカウント“1”を使う。いくつかの印刷ファイルは それに送られないが(例えば画像ファイル)、それらはほとんど1ページのジョブである。 これはまた、それらのファイルを“raw”(すなわちそれらに何も変更をせず、 フィルタリングもしない)すぷーすする、クライアントコンピュータとCUPS/Samba上で動いている、 対象プリンター用のプロプラエティなドライバーは、1ページとして計測するということでもある!
課金を行える機会を得るために、それらのクライアントからPostScriptで送る必要がある (すなわち、そこでPostScriptドライバーを動かす)。もしも、プリンターが非PostScriptモデル ならば、対象のプリンター用に印刷可能な形式にファイルを変換するためのジョブを、CUPSで 行わせる必要がある。Linuxprinting.orgにはドライバーの リストがある。
CUPS 1.1.16より前は、Windowsクライアント上でAdobe PostScriptドライバーを使うことが出来る
のみであった。このドライバーの出力は、CUPS/Sambaサイド上のpstops
フィルタに常時渡されるわけではなく、そのため、正しく計測出来なかった(その理由は、
それがしばしば使用されるPPDに依存するからであり、CUPSにpstops
を
スキップさせる真のPostScriptの直前にPJL-ヘッダーが書かれ、直接pstoraster
ステージに行くからである)。
CUPS 1.1.16とそれ以降のリリースから、Windows NT/200x/XPクライアント用のCUPS PostScript
ドライバーを使うことが出来る(これはcups-samba-1.1.16.tar.gz
という
パッケージとしてhttp://www.cups.org/
のダウンロード領域中に
タグされている)。これはWindows 9x/Meクライアントでは動かないが
以下は保証される:
この組み合わせによる設定についてのより詳細は、cupsaddsmb
のマニュアル
ページで読むことが出来る(これはCUPSがインストールされている所でのみに存在し1.1.16
以降で有効である)。
ジョブの各ページに対するpage_log
中のCUPSログの項目は以下の通り:
プリンター名(Printer name)
ユーザー名(User name)
ジョブID(Job ID)
印刷時間(Time of printing)
ページ数(Page number)
印刷部数(Number of copies)
課金情報文字列(A billing information string) (オプション)
ジョブを送り出したホスト(The host that sent the job) (バージョン1.1.19以降)
以下は項目を含む形式の図示を行うための、CUPSサーバーのpage_log
ファイル
から抜き出したものである:
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13 Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33
これはジョブID401
で、tec_IS2027
上で
ユーザーkurt
によって印刷され、64ページのジョブで三部印刷され、
#marketing
に請求が行き、IPアドレス10.160.50.13.
から送られた。次のジョブはIDが402
であり、ユーザー
boss
によって、10.160.51.33
というIP
アドレスから送られ、1ページ、440部印刷され、finance-dep
に
請求が行った。
何か問題か欠点がこのquotaシステムにあるだろうか?
The ones named above (プリンターハードウェアが壊れたなどの場合に 間違ってジョブが記録される)。
実際、CUPSは、物理的にプリンターデバイスから出て行った紙の代わりに ソフトウェアで処理されたジョブのページをカウントする (すなわち、RIPを使って)。そのため、もしも1000ページ印刷中に五枚目でジャムが 発生し、ジョブがプリンターによって中断した場合、そのジョブに対しては1000ページ 印刷していると引き続き表示される。
すべてのquotaはすべてのユーザーに対して同じであり(事務員よりも 管理者の方により大きなquotaを割り当てるような自由度がない)、グループの サポートもない。
現在のバランス(current balance??)と、現在のquotaに関する “使い切った”分を読む方法がない。
quotaが100で99まで使ったユーザーは、まだ1000ページのジョブを 送信し印刷できる。
quotaの制限に引っかかっりジョブが拒否されたユーザーは、 CUPSから“client-error-not-possible”という意味のあるメッセージを 受け取れない。
これは現在使えるものの中で最も優れたシステムであり、CUPS 1.2にむけて大量の改善が 行われている:
ページカウントはバックエンドに移行する(それらはプリンターと 直接通信し、実際の印刷処理に計数が同期する)。そのため、5枚目でジャムが発生した 場合、カウントを中断する)
quotaはより自由度が向上する。
おそらく前もって、使用しているアカウントについてユーザーが 問い合わせる機能をサポートする。
おそらく、このトピックの周辺にあるような他のツールのいくつかを サポートするだろう。
PPDを使わない、それに関係する印刷キューは、
“raw”プリンターで、スプーラが受け取ったすべてのファイルはそのまま直接
送られる。例外は、パススルー機能を有効とすることが必要とされる
application/octet-stream
ファイルタイプである。“raw”
キューはフィルタリングを全く行わない。それはCUPSバックエンドに直接送られる。この
バックエンドはデバイスにデータを送る事に責任がある(“device URI”として、
例えばlpd://, socket://, smb://, ipp://, http://, parallel:/, serial:/, usb:/
など)。
cupsomatic/FoomaticはネイティブなCUPSドライバーではなく、CUPSには
同梱されない。これらはLinuxprinting.orgで開発されたサードパーティアドオンである。
同様に、すべてのモデルで、CUPS経由でも動くようにさせる、優れたハックであり(
伝統的なスプーラで、Ghostscriptドライバー/フィルタによって動作する)、他のスプーラでの
品質と(良くも悪くも)同じである。cupsomatic
は、単なる媒体
である。すなわち、通常ネイティブなCUPSpstoraster
フィルタが
起動される、CUPSフィルタリングチェーン中のそのステージで、Ghostscriptコマンドラインを
実行する。cupsomatic
はpstoraster
を
バイパスし、CUPSからの印刷ファイルを横取りし、Ghostscriptにリダイレクトする。CUPSは、
関連するcupsomatic/foomatic-PPDが以下のように指定するのでこれを許可する:
*cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
この行は、かつてMIMEタイプ
application/vnd.cups-postscript
にうまく変換した
cupsomatic
に対してファイルを扱わせることをCUPSに指示する。
この変換は、その場で、/etc/cups/mime.types
中の変更に一致する、
application/octet-stream
に自動タイプされた
Windowsから来たジョブに対しては起こらない。
CUPSは、関連するフィルタリング機能を含め、広範囲に設定が出来、自由度が高い。
いくつかの状況に置ける他の問題は、/etc/cups/mime.types
に
以下のようなエントリがある場合である:
application/postscript application/vnd.cups-raw 0 - application/vnd.cups-postscript application/vnd.cups-raw 0 -
これは、すべてのPostScriptファイルをフィルタされないようにする(というよりは、 “-”で指定された仮想のnullfilterに渡す)。これは、 PostScriptプリンターのみに便利である。もしも、非PostScriptプリンターにPostScriptコードを 印刷したい場合(ASCCテキスト印刷のサポートを提供している)、以下のエントリは便利である:
*/* application/vnd.cups-raw 0 -
そして、さらなる処理をせずにすべてのファイルを効率的に バックエンドに送るだろう。
以下のエントリを使用しても良い:
application/vnd.cups-postscript application/vnd.cups-raw 0 \ my_PJL_stripping_filter
PostScriptを解析する(シェルスクリプトであり得る)
my_PJL_stripping_filter
を書き、望まないPJLを取り除く
必要があるかもしれない。これはCUPSフィルタデザインに従う必要がある(主に、printername,
job-id,username, jobtitle, copies, print optionsと可能ならばファイル名
パラメーターを受け渡す)。これは/usr/lib/cups/filters/
中に
誰でも実行できるようにインストールされ、MIMEタイプ
application/vnd.cups-postscript
が来た場合には、
CUPSによって呼び出される。
CUPSは-o job-hold-until=indefinite
を扱える。これは、キュー中に
ジョブを保存しておく。プリンター操作者によって手動で解放されるときにのみ印刷される。
これは、誰も直接アクセスできないいくつかの大きなマシン上で、数百人のユーザーのジョブを、
少数のオペレータが管理する、多くの集中印刷センタからの要求である(これは、ダイレクト
メール発送のためなどに要求される10000ページのジョブを動かす前に、オペレータが
適切な紙を設置する必要がしばしばある場合など)。
Sambaは2つのスプールディレクトリ経由で印刷ファイルを渡す。1つはSambaによって管理される
入力ディレクトリである(smb.conf
中の[printers]
セクション中の
path = /var/spool/sambaディレクティブで設定される)。
もう1つは、UNIX印刷システムのスプールディレクトリである。CUPS用には、通常それは
/var/spool/cups/
であり、cupsd.conf
中の
ディレクティブRequestRoot /var/spool/cups
によって設定される。
CUPS設定ファイルcupsd.conf
中で設定される、いくつかの
重要なパラメーターは以下の通り:
これは、cupsdに、いくつかのジョブの詳細を保存させる(すなわち、c12345,c12346の ように、旧形式であるBSD-LPD制御ファイルのような同等のジョブとして処理し、 CUPSスプールディレクトリ中のファイルに)。既定値は“Yes”に 設定される。
これは、ジョブファイルそれ自身をcupsdが保存するようにさせる(d12345,d12346 などで、CUPSスプールディレクトリ中にファイルされる)。CUPSの既定値は “No”である。
このディレクティブは、メモリ中に保持されるジョブの最大数を制御する。この 制限値にジョブが到達すると、新しいもののために、最も古いものが自動的にシステム からパージされる。もしも既存のすべてのジョブが、引き続きペンディングか アクティブならば、新しいジョブは拒否される。値を0に設定するとこの機能が無効に なる。既定値の設定は0である。
(MaxJobsPerUser
とMaxJobsPerPrinter
という
追加の設定もある)。
すべてをきちんと動くようにするために、以下の3つを行う必要がある:
libcups
を指定してSambaのsmbdをコンパイルする
(Linuxではldd `which smbd'
を動かすことで確認)。
Sambaのsmb.conf
でprinting = cups
を設定する。
Sambaのsmb.conf
でprintcap = cups
も設定する。
この場合、他の手動で設定する印刷関係のコマンド( print command, lpq command, lprm command, lppause command, と lpresume commandのようなもの)は無視され、通常印刷に関しては なんの影響も与えなくなる。
すべてを手動で行いたいならば、printing = cupsを printing = bsdに置き換える。そうすると手動で設定した コマンドが動作し(テストはしていないが)、 print command = lp -d %P %s; rm %sが期待通りの 事を行うだろう。
時々、SambaからWindowsに接続されたプリンターに
印刷をするにはどうしたらいいか、という質問が来ることがある。通常Windowsホストから
プリンターへのローカル接続はUSBまたはパラレルケーブルで行われるが、これはSambaにとっては
重要ではない。ここから、Windowsホストに対してSMB接続でオープンする事のみが必要である。
もちろん、プリンターはまず共有されねばならない。今まで学習してきたように、CUPSはプリンターや
他のサービスと通信するバックエンドを使える。Windowsで共有された
プリンターと通信するには、(驚くべき事だが)smb
バックエンドを使う必要が
ある。まずsmb
ファイルをそこで捜す必要がある。それは
smbspool
へのシンボリックリンクであり、ファイルは存在して実行可能で
なければならない:
root#
ls -l /usr/lib/cups/backend/
total 253 drwxr-xr-x 3 root root 720 Apr 30 19:04 . drwxr-xr-x 6 root root 125 Dec 19 17:13 .. -rwxr-xr-x 1 root root 10692 Feb 16 21:29 canon -rwxr-xr-x 1 root root 10692 Feb 16 21:29 epson lrwxrwxrwx 1 root root 3 Apr 17 22:50 http -> ipp -rwxr-xr-x 1 root root 17316 Apr 17 22:50 ipp -rwxr-xr-x 1 root root 15420 Apr 20 17:01 lpd -rwxr-xr-x 1 root root 8656 Apr 20 17:01 parallel -rwxr-xr-x 1 root root 2162 Mar 31 23:15 pdfdistiller lrwxrwxrwx 1 root root 25 Apr 30 19:04 ptal -> /usr/sbin/ptal-cups -rwxr-xr-x 1 root root 6284 Apr 20 17:01 scsi lrwxrwxrwx 1 root root 17 Apr 2 03:11 smb -> /usr/bin/smbspool -rwxr-xr-x 1 root root 7912 Apr 20 17:01 socket -rwxr-xr-x 1 root root 9012 Apr 20 17:01 usbroot#
ls -l `which smbspool`
-rwxr-xr-x 1 root root 563245 Dec 28 14:49 /usr/bin/smbspool
もしもシンボリックリンクがなければそれを作成する:
root#
ln -s `which smbspool` /usr/lib/cups/backend/smb
smbspool
は、CUPS関係者のMike Sweetによって書かれた。これは、Sambaに
同梱されている。これはまた、CUPS以外の印刷サブシステムで使われ、Windowsプリンター共有の
ためにジョブをスプールする。CUPS上でwinprinter
プリンターを
設定するためには、そのためのドライバーが必要である。本質的に、これは、プリンターが理解できる
(Windowsホストは、送ったファイルを形式変換する能力はない)ファイル形式用に、CUPS/Samba
ホスト上で、印刷データを変換することを意味する。これはまた、使用しているSamba/CUPS
ホストに直接繋がっている場合、プリンターに対して印刷出来るべきであると言うことを意味する。
トラブルシューティングのために、一連の手続きのその部分が順番になっている場合、
これが、何をすべきかを決定すべきかということである。次に、Windowsホストに対する
接続/認証を修正することなどを行う。
バックエンドがCUPSのsmb
を使うプリンターをインストールするために、
以下のコマンドを使う:
root#
lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename \ -P /path/to/PPD
PPDは、そのターゲットモデルのために、印刷データを生成するために、直接CUPSを管理する必要が
ある。PostScriptプリンターのためには、Windows NT PostScriptドライバーを使うPPDを使う。しかし、
パスワードがないとプリンターにアクセスできない場合、一体何が出来るだろうか?あるいは、もしも
プリンターのホストが他のワークグループのだった場合は?これには以下の方策がある:
以下のように、smb://
デバイスURIの一部として、要求されたパラメーターを
含めることが出来る:
smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename
smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename
smb://username:password@WINDOWSNETBIOSNAME/printersharename
ログファイルに書かれる前に、ユーザー名とパスワードが削除されたとしても、デバイスURLは
Sambaサーバー上のプロセス一覧で見えてしまうことに注意(すなわち、誰かが、Linux上で
ps -aux
コマンドを使うと)。これは、本質的に脆弱性のあるオプション
である。しかし、これが唯一の解である。パスワードを保護したい場合、これを使わないこと。
パスワードを要求しないプリンターの共有の方が優れている!印刷は、NetBIOS名前解決が起動し、
動作している時にのみ動く。これはCUPSの機能であり、smbdを動かす必要はないことに注意。
Windows 9x/Me用クライアント用には、最大8文字までのプリンター名を必要とする (あるいは、“8文字に3文字の拡張子”)。そうでないと、 Sambaからそれらをダウンロードするときに、ドライバーファイルが転送できない。
security = userを設定したか?
Sambaアカウントのrootとしてsmbpasswd
を使ったか?
アカウントを作成するために、smbpasswd -a root
を使い、
最初の質問にパスワードを入れる。あるいは、Enterを二回入力することで、
ループを終了する(パスワードを入力しないで)。
もしも、エラーが“Tree connect failed: NT_STATUS_BAD_NETWORK_NAME”
ならば、/etc/samba/drivers
ディレクトリを作成するのを忘れている。
もしもcupsaddsmb
かrpcclient addriver
が、
WERR_BAD_PASSWORDというエラーメッセージを出す場合は、
the previous common errorを参照すること。
“cupsaddsmb”を使うと、PPDが存在する間、 “No PPD file for printer...”というメッセージが出る。 この問題の理由は?
CUPS上でプリンター共有を有効にしていないだろうか?これは、
“cupsaddsmb”が動いているホストからのアクセスを拒否する、
CUPSサーバーのcupsd.conf
中に、
<Location /printers>....</Location>
があるということである。cupsaddsmbをリモートで使っているか、
-h
パラメーターを付けて:
cupsaddsmb -H sambaserver -h cupsserver -v printername
として使っている場合、これは問題となりえる。
cupsd.conf
中のTempDir
ディレクティブが正しい値に設定されているだろうか?またそれは書き込み可能だろうか?
ひとたび間違ったユーザー(たとえば、map to guest = bad user
を設定した場合、しばしば発生するnobody
など)で接続すると、Windows
エクスプローラーは異なったユーザーで再度接続する試みを受け付けない。Sambaに対しては全くデータ
転送が出来ないが、Sambaがアクセスを拒否したと考えられる不可解なメッセージが表示され
続ける。有効な接続の状態をsmbstatus
で確認すること。そして、当該の
プロセス(PID)をKillする。まだ再接続は出来なく、接続しようとすると、
You can't connect with a second account from the same machine
というメッセージがすぐに出る。再説俗を試みても、、まだ1バイトもSambaには届かない
(ログを見ること。“ethereal”を使う)。Windows上のすべてのエクスプローラーを
閉じる。 これは確立した接続としてメモリ中にキャッシュされたものを、Windowsに
捨てさせる。次に正しいユーザーで接続する。一番良い方法は、DOSターミナルウィンドウを
使い、最初に
net use z: \\GANDALF\print$ /user:root
を行う。
異なったアカウントで接続されたと言うことを、smbstatus
で確認する。
この後、プリンターフォルダーを開き(Sambaサーバー上の
ネットワークコンピュータで)、質問中のプリンター上で右クリックし、
を選択する。
nobodyとして接続されていることをsmbstatus
で確認するが、
本当はrootかprinter adminにしたい。これは、おそらく、正しくないユーザー名(たぶん
何らかのミス)を指定した時に、黙ってguest accountとする、
map to guest = bad userのせいであろう。
これを防ぐためには、map to guestを取り除く。
この情報は、Microsoft Windows NT/200x/XPクライアント上で、AdobeドライバーからCUPSドライバーに アップグレードした時、それに関連した問題の体験を、メーリングリスト上に投稿されたもの によっている。
最初に、すべての古い、Adobeが使っているプリンターを削除する。次に、すべとの古い Adobeドライバーを削除する(Windows 200x/XP上では、プリンターフォルダーの 背景部分で右クリックし、 を選択し、 ドライバータブを選択し、ここで削除する)。
“そのままの”rootユーザー名を使っていないか?以下の方法を
試してみよう:
cupsaddsmb -U
>
(2つのバックスラッシュ:最初のものは二番目のものを“エスケープ”
する事に注意)。DOMAINNAME
\\root -v printername
クライアント上のプリンターの削除は、ドライバーも一緒に削除はしない (それを確かめるために、プリンターフォルダーの白い背景部分で 右クリックし、 を選択し、 ドライバータブをクリックする)。これら同じ古いドライバーは、 同じ名前でプリンターをインストールする時に再度使われる。もしも、新しいドライバーに アップデートしたい場合は、古いものを最初に削除する。削除は、同じドライバーを使う他の プリンターが無い場合にのみ可能である。
Windows XPは“ユーザー単位に”SMBプリンターを扱うことが出来る。
これは、すべてのユーザーは自分自身でプリンターをインストールする必要があることを意味する。
すべてのユーザーに対してプリンターを有効にするためには、Windows XPにおける内蔵IPP
クライアントの機能を使う事になるかもしれない。
http://cupsserver:631/printers/printername
という印刷パスで
プリンターを追加する。これについては引き続き調査中である。おそらく、すべてのユーザーに対して
自動的にプリンターのインストールが出来るログオンスクリプトかもしれない。
印刷の変更のために、NT++クライアント上でその機能に通知する。これらは
最初にサーバー
サービスを動かす必要がある(XP中では
File & Print Sharing for MS Networks
に名前が変わっている)。
Windows XP SP1では、ポイントアンドプリントの制限ポリシーが導入された(この制限は、
“Administrator”か“Power User”グループのユーザーには適用されない)。
グループポリシーオブジェクトエディター中で、
に
行く。ポリシーは自動的に有効
に設定され、
ユーザーはそのフォレスト中のマシンに対してのみポイントアンドプリント
が
使える。おそらく、無効
か、ドライバーのダウンロードをSambaから出来るように、
ユーザーはそれらのサーバーに対してのみポイントアンドプリントが使える
それを変更する必要がある。
何をしているのだろうか?間違っているに違いない(しかし、これを発見するのは容易では ない)。すべてを設定するように見えるダイアログを表示するための、 3つの異なった方法がある。それら3つのダイアログは、同じように見える が、そのうちの1つのみが意図しているものである。これをすべてのユーザーに対して行うために、 AdministratorかPrint Administratorである必要がある。XP上でどのようにやるかは以下の通り:
最初の間違った方法:
Printersフォルダーを開く。
プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュー を選択する。
細かくこのダイアログを見、なりが見えるかを覚えておく。
二番目の間違った方法:
プリンターフォルダーを開く
プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュー を選択する。
全般タブをクリックする。
ボタンを クリックする。
新しいダイアログが開く。このダイアログを開いたままにし、 親のダイアログに戻る。
三番目の正しい方法:
プリンターフォルダーを開く。
プリンター(cupshost上のremoteprinter) を右クリックし、コンテキストメニュー を選択する。
詳細タブをクリックする (もしもすべてが“灰色になっていて入力できないならば”、 十分な権限を持つユーザーとしてログインしていない)。
ボタンを クリックする
2つの新しいタブのどちらかで、
ボタンをクリックする。新しいダイアログが開く。これを、 “B.5” または "A.3"で同様のものと比べてみる。
違いがわかるだろうか?私にはわからない。しかし、“C.1. から C.6.”の手順で
到達した最後のもののみ、任意の設定を恒久的に保存し、新しいユーザーの既定値となる。もしも、
すべてのユーザーに同じ既定値を設定したいならば、これらのステップを
as Administrator(smb.conf
中でprinter admin
であるもの)で、クライアントが、(クライアントが、以下の手順Aまたは
B)によって、各固有の、ユーザー単位の既定値を
設定出来る)ドライバーをダウンロードする前に行う必要がある。
Optimize for Speed
を使わずに、代わりに、
Optimize for Portability
を使う(Adobe PSドライバーの場合)。
Page Independence: No
を使わない。常時、
Page Independence: Yes
を使う(Windows NT/200x/XP用の、
Microsoft PDドライバーとCUPS PSドライバー)。もしもフォントに問題がある場合には、
Download as Softfont into printer
を使う(Adobe PS
ドライバーの場合)。TrueType Download Optionsオプション用に、
Outline
を選択する。もしも、非PSプリンターでトラブルがあるか、
選択できる場合はPostScript Level 2を使う。
以下と同様: cupsaddsmb
の最後のコマンドが完全に終わっていない。もしも、
cmd = setdriver printername printername
の結果が
NT_STATUS_UNSUCCESSFULの場合、おそらくプリンターがまだSambaによって認識されていない。
ネットワークコンピュータ中に表示されているだろうか?
rpcclient hostname -c `enumprinters'
で表示されるだろうか?
smbdを再起動(か、smbstatus
で一覧表示されるすべてのプロセスに対して
kill -HUP
を行う)し、再度試してみる。
同じ位置へのCUPSスプールディレクトリの設定で、以前に何か問題が起きなかったか?
(cupsd.conf
中のRequestRoot /var/spool/samba/
か、
その逆:[printers]
セクション中で、
/var/spool/cups/
をpath>として設定しているか)?
これらは異なってなければならない
。cupsd.conf
中のRequestRoot /var/spool/cups/
とsmb.conf
の
[printers]
セクション中の
path = /var/spool/sambaを設定する。それ以外は、
cupsdは再起動後毎回そのスプールディレクトリのアクセス許可を整理するので、印刷は確実に
うまくいかない。
この場合、“lp”という名前の印刷キューが、間欠的にジョブを取りこぼし、 送られたものとは完全に違うものを出力する。
プリンターに対して“lp”という名前を付けるのは好ましくない。これは、伝統的な
UNIXにおける既定値のプリンターである。CUPSは暗黙のクラスを自動的に作成する事を行うように
設定されているかもしれない。これは、デバイスをプールするために同じ名前のすべてのプリンターを
グループ化するためと、ラウンドロビン方式でジョブのロードバランスを取るということである。
誰かが“lp”という名前のプリンターを持っている場合にもこれがあり得る。その人の
ジョブを受け取り、無意識にその人のデバイスに自分のジョブを送っているかもしれない。
プリンター名に対して厳密の制御をするためには、巨大なネットワーク環境において起こるかも
しれない事に対する、より良い制御を行う、BrowseShortNames No
を
設定する。
Table of Contents
Samba-3から、スタッカブルVFS(バーチャルファイルシステム)モジュールがサポートされる。 SambaはUNIXファイルシステムへのアクセスリクエストの一つ一つを、ロードされた VFSモジュールに渡す。この章は、Sambaのソースに附属のモジュールについて説明すると同時に、 一部の外部モジュールについても言及する。
異なるシステムでは異なる方法で共用ライブラリーをコンパイルしリンクするので、これらの モジュールが、プラットフォームディストリビューションのバイナリSambaパッケージと共に 供給されない場合、モジュールをコンパイルするのが困難になるかもしれない。これらの モジュールは、GNU/Linux及びIRIXに関してテスト済みである。
VFS モジュールを使用するには、以下の例に類似した共有を作成すること。重要なパラメーターは、 一つ以上のVFSモジュールを名前順に一覧表示できるvfs objects パラメーターである。例えば、ファイルへのアクセスをすべてログに取り、削除されたファイルを ゴミ箱に入れるには、VFSモジュールを使うsmb.confの例を 参照のこと:
モジュールは指定された順に使用される。例えば、ウィルススキャナモジュールとごみ箱 モジュールを両方使用したいとする。この場合、ファイルに関して他のアクションが 取られる前に、最初にウィルスを検知するよう、ウィルススキャナモジュールを最初の モジュールとし、このモジュールが最初に動くようにすべきである。 The modules are used in the order in which they are specified. Let's say that you want to both have a virus scanner module and a recycle bin module. It is wise to put the virus scanner module as the first one so that it is the first to get run and may detect a virus immediately, before any action is performed on that file. vfs objects = vscan-clamav recycle
SambaはSambaをインストールしたサーバーのrootディレクトリ中の/lib
からいくつかのモジュールをロードしようとする(通常は
/usr/lib/samba/vfs
か/usr/local/samba/lib/vfs
)。
いくつかのモジュールは同じ共有に対して二度使用できる。これは 複数のVFSモジュールを使用するsmb.confの例の ような設定で可能となる。
syslog機能へのファイルアクセスを監査するシンプルなモジュールである。 以下の操作のログが取られる:
share
connect/disconnect
directory opens/create/remove
file open/close/rename/unlink/chmod
このモジュールは、Samba-3サーバー上で格納される既定値のquota値を、Windowsのエクスプローラーの GUI画面で設定できるようにする。この試みはLinuxファイルシステムでユーザーとグループに対する quotaを格納する場合のみだが、それは既定値を持たない。
Sambaは既定値としてNO_LIMITをquotaの既定値として返し、それは更新できない。このモジュールを 使うと、ユーザーに対するquotaレコード中でWindowsクライアントに表示される既定値のquota値を 格納できる。既定値では、通常quota制限がrootには適用されないため、rootユーザーが既定値として 利用される。
このモジュールにはsmb.conf
ファイル中で2つのパラメーターを設定する。おのおのの既定値の
プレフィックスは“default_quota”である。これは、以下のようにして、
vfs modulesパラメーター中でモジュールをロードしたときに上書きできる:
vfs objects = default_quota:myprefix
default_quotasモジュールに対して指定することが出来るパラメーターのエントリは以下の通り:
既定値のユーザーquotaを格納するために使われるquotaレコードのためのuidを 指定する整数値。
既定値は0(ルートユーザー)。使用例は以下の通り:
vfs objects = default_quota default_quota: uid = 65534
上記の例ではmyprefix
が省略され、そのため、既定値の
プレフィックスはモジュールの名前になる。myprefix
パラメーターが指定されると、上記は以下のように書き換えられる:
vfs objects = default_quota:myprefix myprefix: uid = 65534
既定値のquota値がユーザーのレコードとしても表示される場合か、
NO_LIMIT
が、prefix:uid
パラメーターに
よって指定されたユーザーとしてWindowsクライアントに表示される場合、この
パラメーターは論理値となる。
既定値はyes
である(NO_LIMITが表示される)。使用例は以下の通り:
vfs objects = default_quota:myprefix myprefix: uid nolimit = no
このパラメーターはprefix>:uid
と同じように整数値を引数と
して取るが、グループquotaであるところが違う。注意:グループquotaはWindows
エクスプローラーではサポートされていない。
既定値は0である(rootグループ)。使用例は以下の通り:
vfs objects = default_quota default_quota: gid = 65534
このパラメーターは、prefix>:uid nolimit
と同じように
真理値を取るが、グループquotaであることが違う。注意:グループquotaは
Windowsエクスプローラーではサポートされていない。
既定値はyes
(NO_LIMITが表示される)。使用例は以下の通り:
vfs objects = default_quota default_quota: uid nolimit = no
複数のパラメーターを組み合わせた使用例は以下の通り:
... vfs objects = default_quota:quotasettings quotasettings: uid nolimit = no quotasettings: gid = 65534 quotasettings: gid nolimit = no ...
このモジュールは上記のaudit
モジュールとほぼ同じで
あるが、監査ログをsyslogとsmbd
のログファイルに送る
事が異なる。このモジュールのlog levelは
smb.conf
ファイル中で設定する。
有効な設定と記録される情報を下記のテーブル中に示す。
Table 23.1. 拡張監査ログの情報内容
ログレベル | ログ内容 - ファイルとディレクトリ操作 |
---|---|
0 | ディレクトリの作成、削除、Unlink |
1 | ディレクトリのオープン/改名、ファイル名の変更、パーミッション/ACLの変更 |
2 | ファイルのオープン&クローズ |
10 | 最大のデバッグレベル |
この監査ツールはたいていの人が容易に認知するよりもより自由度が高い。 有用なログ情報を記録するためのいくつかの方法がある。
すべてのトランザクションを記録するためにsyslogが使える。
これは、smb.conf
ファイル中に
syslog = 0
を設定することで無効に出来る。
xがログレベルであるlog level = 0 vfs:x
をsmb.conf
ファイル中に設定することによりすべてのロードされた
VFSモジュールに対して既定値のログファイル
(log.smbd
)をログの出力として使える。これは、
ログレベルで指定された、VFSモジュールの動作のすべてのログが
有効になっているが、通常のログは無効にする。
ユーザー単位、クライアントマシン単位などで詳細なログを取れる。
これは、log file
の特別な設定方法と
上記を一緒にすることを要求する。
ユーザー単位とマシン単位の詳細なログの例は、 log file = /var/log/samba/%U.%m.log のようにして行う。
監査情報は、しばしば長い期間保存する必要はある。ログファイルがローテート
されないように、smb.conf
ファイル中でmax log size = 0
を設定するのは必須である。
このモジュールは、(UNIX配下のSambaサーバーで)移動プロファイルのファイルと ディレクトリを読み込み専用に設定することができるようにするために作成 された。 このモジュールは、プロファイル共有にインストールされている場合、 プロファイルのファイルとディレクトリが書き込み可能であると、クライアントに 通知する。これにより、クライアントがログアウトまたはシャットダウンした 時に、ファイルを上書きしなくなるが、クライアントのニーズは充足する。
ゴミ箱と同様のモジュールである。 使用すると、unlinkシステムコールを 横取り、ファイルを削除する代わりにゴミ箱ディレクトリに移動する。 これはWindowsコンピュータにおけるゴミ箱の機能と 同じである。
ごみ箱は、Windows エクスプローラー
のネットワークファイルシステム(共有)のビューにも、マッピングされたドライブの
いずれのビューにも表示されない。その代わりに、.recycle
というディレクトリが、初めてファイルを削除したときと
recycle:repository
が設定されていないときに自動的に
作成される。もし、recycle:repository
が設定されている
場合、作成されるディレクトリはrecycle:repository
に
依存する。ユーザーはごみ箱からファイルを取り戻すことが出来る。もしも、
recycle:keeptree
が指定されていた場合、
削除されたファイルは、ファイルが削除された元の場所と同一のパスから、
見つけることができる。
recycle
がサポートするオプションは以下の通り:
recycleディレクトリに設定したい8進のモードを指定する。
もしも存在しないか、最初にファイルが削除された時、
このモードでrecycleディレクトリが作成される。
もしも、recycle:subdir_mode
が
設定されていない場合、それらのモードはサブディレクトリ
にも適用される。もしも、
directory_mode
が設定されて
いない場合、既定値として0700が使われる。
recycleディレクトリのサブディレクトリに設定したい
8進のモードを指定する。このモードでサブディレクトリ
が作成される。もしも、
recycle:subdir_mode
が
設定されていない場合、サブディレクトリのモードは
directory_mode
のモードで
作成される。
このオプションを設定すると、同名の二つのファイルが削除
されたとき、 二つとも別のファイルとしてゴミ箱に保存する。
より新しい方の削除ファイルは、
“Copy #x of filename
”
という名称で保存される。
recycle:versionsの反対である(*や?のワイルドカードもサポート) する。recycle:versionsが有効な時に 便利である。
netatalkモジュールは、Sambaとnetatalkのファイル共有サービスの共存を やり易くする。
従前のnetatalkモジュールと比較した長所は以下の通り:
.AppleDouble フォークの作成を気にかけず、ただ同期を取る。
smb.conf
中の共有の「隠し(hide)」または「拒否(veto)」
リスト中に.AppleDoubleのアイテムを含まないとき、自動的に追加される。
これはバックアップでも、アーカイブでも、バージョンコントロールソリューションでもない!
SambaかWindowsサーバーでは、shadow_copyはエンドユーザーツールとしてのみ設計されて いる。バックアップやアーカイブソリューションの機能強化や置き換えにはならず、 そのように考えてはいけない。更に、バージョンコントロール機能が必要な場合には、 バージョンコントロールシステムを入れること。これは警告である。
shadow_copyモジュールはMicrosoftシャドーコピーサービスに似た機能を提供する。 適切に設定された場合、Sambaの共有上で、Microsoftシャドーコピークライアントが "シャドーコピー"を見えるようにする。シャドーコピークライアントのインストール が必要である。Microsoftシャドーコピークライアントは ここ から入手できる。Windows XPより前のクライアントには追加の要求があることに注意。 この機能はWindows XPより前のバージョンではテストされていない。Microsoftシャドーコピー に関するより詳細な情報は、 Microsoftのサイト を参照のこと。
shadow_copy VFSモジュールはLVM1、LVM2かEVMSのような、ある種の論理ボリューム マネージャ(LVM)でセットアップしたものがベースのファイルシステムを要求する。 LVMの設定はこの文書の範囲外である。しかし、例としてのみ この機能をテストするために行う手順の概要を示す。使いたいとしているLVMの 実装が使用対象に対して準備されているかを確かめる必要がある。十分にテストは されなければならない。
以下は、LVMとEVMSに対するよく使われる情報源である:
The LVM HOWTO (訳注:日本語訳はこちら)
Daniel Robbinによる、よく書かれた、LVMソースコードとreiserfsを使ったLinux上の2つのパートに分かれたチュートリアル Learning Linux LVM, Part 1 と Learning Linux LWM, Part 2を参照。
これを書いている時点では、十分なテストは終わっていない。シャドーコピーVFS モジュールを、製品環境では展開していないが、概念の照明としてはより多く、 特定のシナリオでテストした。シナリオはXFSファイルシステムとLVM1を使う Debian Sarge上のSamba-3サーバーで改良された。ここで提示されたすべてのコンポーネント に関して、十分な評価をしないでソリューションとして使うことは推奨しない。 すなわち、以下は動作させたまでの基本的な概要である。
インストールされたOS. テストを行うにあたっては、 Debian Sarge (すなわちテスト版)をXFSファイルシステム上で使用した。OSの設定は、 この文書の範囲外である。Sambaが動作するOSがあるものと仮定する。
Sambaのインストールと設定. この件についてはこのHOWTOのインストールの章 を参照のこと。ドメインコントローラーかメンバーファイルサーバーであることは重要では ないが、Samba 3.0.3かそれ以降のサーバーが動作していることを仮定する。
LVMのインストールと設定. クライアントに対してシャドーコピーを有効にする前に、シャドーコピーを 作っておく必要がある。これはファイルシステムのスナップショットのような 事を行う事でできる。スナップショットはLVMのような、論理ボリューム マネージャでの一般的な機能であり、まずこれを最初に設定する必要がある。
以下は、Debianユーザーにとっては最も手助けとなる例である。繰り返すが、 これは"testing"または"Sarge"を使ってテストしている。
まだ入れていないのであれば、lvm10とdevfsdパッケージをインストールする。
Debianシステム上では、devfsファイル名を要求するdevfsとlvm1が相互に
影響するので警告が出る。
apt-get update && apt-get install lvm10 devfsd xfsprogs
を実行してこの例のためのトリックを行う。
次にボリュームを作成する。そしてボリュームにパーティションを作成する 必要がある。好みのパーティション作成ツールを使うこと(たとえば、 Linuxのfdisk、cfdiskなど)。パーティションタイプは"Linux LVM"を 表す 0x8eに設定すべきである。この例では/dev/hdb1を使う。
LVMパーティション(タイプ0x8e)が出来ると、LVMボリュームを作成するための
一連のコマンドを実行出来る。いくつかのディスクとパーティションを
使うことが出来るが、この例では一つのみを使う。
modprobe lvm-mod
のようにしてカーネルモジュールを
ロードしてもよく、また、(/etc/modules
に追加
することによって)起動時にロードするように、rebootしても良い。
この時点でlvcreate -L400M -nsh_test shadowvol
のようにして、論理ボリュームを作成できる。
これは、shadowvolとして作成したボリュームグループ内に、400MBの、
"sh_test"という論理ボリュームを作成する。すべてがうまくいくと、
/dev/shadowvol
中にそれらを見る事ができる。
この時点でsh_testという論理ボリュームを
mkfs.xfs /dev/shadowvol/sh_test
というコマンドでフォーマットできる準備が出来た。
選択した任意のファイルシステムで論理ボリュームをフォーマット できるが、ファイルシステムのフリーズ、リサイズや拡張のような LVMの便利な追加機能を使えるようにしておくこと。
以下のようにしてディレクトリを準備する必要がある。 Now we need to prepare the directory with something like
root#
mkdir -p /data/shadow_share
あるいは、シャドーコピーが有効になったSamba共有の希望する名前を
指定する。その上で使えるように、パーミッションの設定をきちんと
行う事。もしも、わからなければ、
chmod 777 /data/shadow_share
を使い、うまく
動いてからパーミッションをきつくする。
mount /dev/shadowvol/sh_test /data/shadow_share
のようにしてLVMボリュームをマウントする。
シャドーコピーVFSモジュールのインストールと設定. 最後に実際のシャドーコピーVFSモジュールを設定する。シャドーコピーVFS モジュールはSamba 3.0.3以降で有効である。smb.confの設定はとても標準的 である。以下はシャドーコピーVFSモジュールを使う共有定義の例である:
スナップショットの作成とシャドーコピーとしての有効化. シャドーコピーを閲覧できる前に、それを作成してマウントする必要がある。 これは、cronジョブとして動作するスクリプトで行うのが最も良い。この特定の 解決方法に、LVMスナップショットを閲覧するのにシャドーコピーVFSモジュールが 使える。これらのスナップショットはモジュールによっては作成されない。また、 モジュールによって有効化もされない。このモジュールは、有効になったスナップ ショットを閲覧する事を、シャドーコピーが有効になったクライアントに対して 行う。
以下はスナップショットの作成とマウントを行う単純なスクリプトである:
#!/bin/bash # This is a test, this is only a test SNAPNAME=`date +%Y.%m.%d-%H.%M.%S` xfs_freeze -f /data/shadow_share/ lvcreate -L10M -s -n $SNAPNAME /dev/shadowvol/sh_test xfs_freeze -u /data/shadow_share/ mkdir /data/shadow_share/@GMT-$SNAPNAME mount /dev/shadowvol/$SNAPNAME \ /data/shadow_share/@GMT-$SNAPNAME -onouuid,ro
このスクリプトはリブート時にスナップショットの再マウントのような事は扱わないことに注意。
クライアントからのテスト. テストのために、 MicrosoftのWebサイト からシャドーコピークライアントを入手し、インストールする必要がある (訳注:URLは日本語版に差し替え済み)。これはXPクライアントでのみテストして いるので、他のXP以前のクライアントでは結果が異なる可能性がある。一度 XPクライアントにインストール後、指定したファイルかshadow_shareの 空白部分で右クリックすると、"プロパティ"が表示される。何か変更があると、 プロパティウィンドウの中に"以前のバージョン"が表示される。
この節では、投稿されてはいるが、SambaCVSツリー(訳注:現在はgit)には何らかの理由(例えば、 管理者が独自のCVSツリーを持つ方が管理しやすいなどの理由)で、現行のものには含まれない、 各種のVFSモジュールを紹介する。
ここで言及したからと言って、そのモジュールの安定性や機能性の良し悪しを示唆したとは解釈しないこと。
URL: Taylors University DatabaeFS
私は、かなり完成された読み込み専用のファイルシステムを実現する VFS モジュールを作成した。 これは、異なるデータベースを使用するための、モジュール式あるいは一般的な方式のファイル システムとしてデータベースからの情報を表示する(元々は、“アーティスト”や “歌詞”といったディレクトリでMP3ファイルを整理するために設計されたもので ある。これを私は、学生名簿データベースに応用した)。ディレクトリ構造はデータベース自身に 保存されており、その表を確認するプログラムが走りますが、それ以外に、データベース構造に 関して何らかの推定をすることはしない。
フィードバックを歓迎する。コメント、提案、パッチ、その他何でも送ってほしい。他に何の 役にも立たなくても、最低、誰かが仮想ファイルシステムを作成したい場合に役に立つことを 願っている。
Samba-vscan は、Sambaが使う共有化のファイルのための、オンアクセスアンチウィルス機能を提供する、 コンセプト実証(POC)モジュールである。samba-vscan は、各種のウィルス・スキャナーをサポートし、 Rainer Linkがメンテナンスを行っている。
Sambaユーザーは何の問題もなくSerNetからのRPMを使っている。OpenLDAP Linuxユーザーも とても良い結果が得られるvscanスキャナを使っている。これは全体を通して書き込みの パフォーマンスに影響がある。
以下のような共有セクションはvscan-clamavを設定したい人のための良いガイドである:
[share] vfs objects = vscan-clamav vscan-clamav: config-file = /etc/samba/vscan-clamav.conf
以下のvscan-clamav.conf
ファイルの例は、完全に動作可能なものの
手助けになるかもしれない:
<title>VFS: Vscan ClamAV制御ファイル</title>
#
# /etc/samba/vscan-clamav.conf
#
[samba-vscan]
; run-time configuration for vscan-samba using
; clamd
; all options are set to default values
; do not scan files larger than X bytes. If set to 0 (default),
; this feature is disable (i.e. all files are scanned)
max file size = 10485760
; log all file access (yes/no). If set to yes, every access will
; be logged. If set to no (default), only access to infected files
; will be logged
verbose file logging = no
; if set to yes (default), a file will be scanned while opening
scan on open = yes
; if set to yes, a file will be scanned while closing (default is yes)
scan on close = yes
; if communication to clamd fails, should access to file denied?
; (default: yes)
deny access on error = no
; if daemon failes with a minor error (corruption, etc.),
; should access to file denied?
; (default: yes)
deny access on minor error = no
; send a warning message via Windows Messenger service
; when virus is found?
; (default: yes)
send warning message = yes
; what to do with an infected file
; quarantine: try to move to quantine directory
; delete: delete infected file
; nothing: do nothing (default)
infected file action = quarantine
; where to put infected files - you really want to change this!
quarantine directory = /opt/clamav/quarantine
; prefix for files in quarantine
quarantine prefix = vir-
; as Windows tries to open a file multiple time in a (very) short time
; of period, samba-vscan use a last recently used file mechanism to avoid
; multiple scans of a file. This setting specified the maximum number of
; elements of the last recently used file list. (default: 100)
max lru files entries = 100
; an entry is invalidad after lru file entry lifetime (in seconds).
; (Default: 5)
lru file entry lifetime = 5
; exclude files from being scanned based on the MIME-type! Semi-colon
; seperated list (default: empty list). Use this with care!
exclude file types =
; socket name of clamd (default: /var/run/clamd). Setting will be ignored if
; libclamav is used
clamd socket name = /tmp/clamd
; limits, if vscan-clamav was build for using the clamav library (libclamav)
; instead of clamd
; maximum number of files in archive (default: 1000)
libclamav max files in archive = 1000
; maximum archived file size, in bytes (default: 10 MB)
libclamav max archived file size = 5242880
; maximum recursion level (default: 5)
libclamav max recursion level = 5
もちろん、これを動作させるためにclamデーモンを走らせることは必要である。これはClamAVを
使うための動作例である。ClamAVの説明には追加の設定例が提供されている。それは、システム
内の/usr/share/doc/
ディレクトリ配下に配置されている。いくつかの例は
他の使用可能なウィルススキャナをターゲットにもしている。
Table of Contents
UNIXとMicrosoft Windows NTを統合化されたログオンで統合することは、長い間 異機種間コンピューティング環境において“聖杯”と考えられてきた。
もう一つ、この機能がなければ、UNIXとMicrosoft Windowsネットワークの相互運用性が 著しく限定されるというものがある。UNIXシステム全般に渡ってファイル共有を 可能にし、ドメインユーザーとグループの所有者を整合性のある形で割り当てられる 機構がなければならない。
winbindは、Sambaシステム中で、統一されたログオンの 問題を解決するコンポーネントである。Winbind は、Microsoft RPC コール、 Pluggable Authentication Modules (PAM)、Name Service SwitchのUNIXの実装を 使用して、Windows NTのドメインユーザーがUNIXマシン上のUNIXユーザーとして動作 できるようにする。この章は、Winbindシステムについて、その機能、設定の仕方、 及び内部的にどのように動いているのかを説明する。
Winbind は、三つの別々の機能を提供する。
ユーザーの本人確認情報の認証(PAM経由)。これは、Windows NT4ドメインか (Sambaドメインも含む)Active Directoryドメインからユーザーとグループ アカウントを使ってUNIX/Linuxシステムにログオンすることを可能にする。
Winbindは、winbind_idmap.tdbと呼ばれるデータベースを維持し、その中に、
UNIX UID/GIDとNT SID間のマッピング情報を格納する。このマッピングは、
ローカルUID/GIDを持たないユーザーまたはグループにのみ使用する。
idmap uid/gid の範囲から割り当てられ、NTのSIDにマッピングされた
UID/GIDが格納される。idmap backend
が
ldap:ldap://hostname[:389]
に指定されている場合、
ローカルのマッピングを使用する代わりに、Winbindは、この情報をLDAP
データベースから取得する。
もしもwinbindd
が実行中ではないとき、smbd
(winbindd
を呼び出す方)は、代替手段として純粋にローカルな
/etc/passwd
と/etc/group
からの情報を
使用することにし、動的マッピングは使用しない。OSでNSSが有効になっている場合、
ユーザーとグループ情報の解決はNSS経由で行われる。
UNIXとMicrosoft Windows NTでは、ユーザー及びグループ情報の見せ方のモデルも、 それを実行するために使用している技術も異なるのは周知の事実である。これが、 二つのシステムを統合して、満足の行く運用をすることを困難にしてきた。
これに対してよく行われる解決策は、UNIXとWindowsの両システム上に全く同名の ユーザーアカウントを作成し、Sambaを使用して、両システム間のファイルサービスと 印刷サービスを提供するというやり方であった。ただし、この解決策は、双方の マシンにユーザーを追加したり削除したりする作業が面倒でパスワードも2セット 持たなければならず、その両方がUNIXとWindowsシステム間の同期のずれの問題に つながり、ユーザーの混乱を招くという、完璧には程遠いものである。
UNIX マシンのための統一されたログオンという問題を、次のように三つの 構成要素に分けることができる:
Windows NTのユーザー及びグループ情報を取得する。
Windows NT ユーザーを認証する。
Windows NT ユーザーのためにパスワードを変更する。
理想的には、統一されたログオンという問題の解決方法は、UNIXマシン上に情報を複製する ことなく、上記の問題を全て満足させ、しかも、 ユーザーやグループ情報をどちらの システムで維持しても、システム管理者の仕事を増やさないというものであってほしい。 Winbind システムは、統一されたログオンという問題の三つの構成要素を簡単に優雅に こなすソリューションを提供するものである。 problem.
Winbindは、UNIXとWindows NTのアカウント管理を、UNIXマシンがNTドメインの完全な メンバーになることを可能にすることによって統一する。一旦これを行えば、UNIX マシンは、NTユーザーやグループをあたかも“ネイティブな”UNIXユーザーや グループであるかのように見ることができるようなり、UNIXのみの環境でNIS+を使用 するのとほぼ同様に、NTドメインを使用することができるようになる。
その結果、UNIX マシン上のプログラムのいずれかが、OSにユーザー名やグループ名の検索を 依頼すると、指定されたドメインを担当する NT のドメインコントローラーにその検索を 依頼することにより、問い合わせは解決する。Winbind は低レベル(Cライブラリ内の NSS名前解決モジュール経由)でOSに繋がるので、NT ドメインコントローラーへの上記の リダイレクションは、完全に透過である。
UNIXマシンのユーザーは、“ネイティブの”UNIX名を使用するのと同様に、 NTユーザー名とグループ名を使用することができる。ユーザーはファイルをchownして、 NTドメインユーザーの所有に変えることもでき、UNIXマシンにログインしてドメイン ユーザーとしてUNIXのX Window Systemセッションを実行することもできる。
Winbindが使用されていることが明らかにわかるところは、ユーザー及びグループの名前が
DOMAIN\user
とDOMAIN\group
の形を取ると
いう点だけである。これは、Winbind が、信頼関係のあるドメインに参照するの特定の
検索について、ドメインコントローラーへのリダイレクト決めるために必要である。
さらに、Winbind は、PAMシステムのhookとしての認証サービスを提供し、NTドメインを 経由して、PAM対応のあらゆるアプリケーションに対して認証を行う。この機能は、一カ所 (ドメインコントローラー上)に全てのパスワードが格納されるため、システム間の パスワード同期の問題を解消する。
NTベースのドメイン基盤がすでにあり、それにUNIX ワークステーションか サーバーを組み入れたいという要望のある組織がWinbindの対象となる。Winbind より、このような組織は別個のアカウント基盤を管理する必要なく、UNIX ワークステーションを展開することができる。これは、NTベースの組織にUNIX ワークステーションを展開するための間接費を大幅に軽減する。
Winbind のもう一つの興味深い使用方法は、UNIXベースの装置の中心部分に 使用することである。Microsoftベースのネットワークにファイルサービスと 印刷サービスを提供する装置は、Winbindを使用することで、ドメインに シームレスに統合される。
外部のSID(foreign SID)という単語は、特定の環境に依存しない 反応としてしばしば見受けられる。以下はSambaメーリングリスト上で起きたやりとりを 書化したものである。これは、winbindの使用に関連してしばしば現れる混乱の良い例で ある。
事実:Winbindはローカルドメインの一部でないワークステーションを使うユーザーを 扱う必要がある。
対応:“なぜ?私はwinbindなしで長い間ドメインに所属していないワークステーション をSambaとともに使っている。winbindは他のSamba/Windows PDCによって制御される ドメイン中のメンバーサーバーとしてのSamba用ではないかと思う。”
もしも、SambaサーバーがローカルSambaドメイン以外のドメインからアクセスされる か、もしも、ローカルドメインメンバーでないマシンからアクセスされる場合、winbindは Sambaドメインのメンバーであるユーザーから分離された外部のユーザーの識別情報を保持する めの割り当てられた領域からUIDとGIDを割り当てる。
これは、winbindは、ドメインメンバーとドメイン非メンバーのワークステーションがある、 単一のSambaPDCがローカルネットワーク上にある場合に甚だしく有用である。もしも、 winbindが使われないと、ドメインのメンバーでないWindowsワークステーション上の georgeというユーザーはPDCとして動作しているSambaサーバーのアカウントデータベース 中のgeorgeと呼ばれるユーザーのファイルにアクセスできる。winbindが使われると、 既定値の状態は、ローカルユーザーのgeorgeがDOMAIN\georgeというアカウントとして 扱われ、外部(ドメインのメンバーでない)アカウントは、おのおの別のSIDを持つために MACHINE\georgeとして扱われる。
Winbindシステムは、クライアント/サーバーアーキテクチャを想定し設計されたもので
ある。長時間走り続けるwinbindd
デーモンがUNIXドメイン
ソケット上でリクエストが来るのを待つ。これらのリクエストは、NSS及びPAM
クライアントにより生成され、順番に処理される。
Winbind を実装するのに使用されている技術を以下に詳述する。
過去数年間、Sambaチームの多くのメンバーが、Microsoftリモートプロシージャ コール(MSRPC)システムの各側面を解明しようと努力してきた。このシステムは、 リモート管理、ユーザー認証、印刷スプーリングを含むWindows NTマシン間の ネットワーク関連操作の大半に使用されている。当初、Sambaへのプライマリ ドメインコントローラー(PDC)機能の実装を支援するために 着手した作業で あったが、結果としてそれ以外の目的に使用できる一連のコードを得ることが できた。
winbind はドメインユーザーとグループを列挙し、個々のユーザーやグループの詳細 情報を取得するために、各種のMSRPC コールを使用する。他のMSRPC コールは、 NTドメインユーザーを認証し、ユーザーのパスワードを変更するために使用できる。 Windows PDCに、直接ユーザー及びグループ情報を問い合わせることで、Winbindは、 NTのアカウント情報をUNIXユーザー名とグループ名にマッピングする。
2001年後半より、SambaはNT4のRPC サービスではなく、“ネイティブモード” のプロトコルを使用して、Microsoft Windows 2000とやり取りする機能を持つ ようになった。LDAP及びKerberosを使用し、winbindを走らせている ドメイン メンバーは、Windows 200xクライアントの世界で行われるのと全く同じように、 ユーザーとグループを列挙でき、そうすることによってより効率的で効果的な winbind の実装を提供する。
Name Service SwitchまたはNSSは、多くのUNIX OSに存在する機能である。 これは、ホスト名、メールの別名、ユーザー情報などのシステム情報を、異なる ソースから解決することを可能にする。例えば、スタンドアロンのUNIXワーク ステーションは、ローカルのファイルシステムに格納されている一連のフラット ファイルからシステム情報を解決できる。ネットワークに繋がったワーク ステーションは、最初にローカルファイルからシステム情報を解決しようとし、 次にユーザー情報についてNISデータベースに問い合わせるか、あるいは、ホスト名 情報についてDNS サーバーに聞くことができる。
UNIXユーザー名とグループの解決の際、NSSのAPIは、winbind が自分をシステム 情報のソースとして見せることを可能にする。winbindは、このインタフェースと MSRPCコールを使用して、Windows NTサーバーから取得した情報を使用して、 アカウント列挙の新しいソースを提供する。標準のUNIXライブラリコールを 利用して、winbind を走らせているUNIXマシン上でユーザーとグループを列挙させ、 NTドメインのみならず、信頼関係のあるいずれのドメインでもその全ユーザーと グループを、あたかも、ローカルユーザーやグループのように見ることができる。
NSSの基本制御ファイルは/etc/nsswitch.conf
である。
UNIXアプリケーションが検索を行うと、Cライブラリは要求されたサービス
タイプに一致する列を/etc/nsswitch.conf
の中で探す。
例えば、ユーザー名またはグループ名の検索の場合、“passwd”の
サービスタイプが使用される。設定の中のこの列が、そのサービスのどの
実装が、どういう順番で試行されるべきか指定している。もし、passwdの
設定列が以下のようになっている場合:
passwd: files example
Cライブラリは、最初に/lib/libnss_files.so
と呼ばれる
モジュールをロードし、次に/lib/libnss_example.so
モジュールをロードする。Cライブラリはこれらのモジュールを順番に動的
ロードし、モジュール内の解決機能を呼んでリクエストを解決しようとする。
要求が解決されると、Cライブラリ は、その結果をアプリケーションに返す。
このNSSインタフェースは、OSへのフックのための、Winbindへの簡単なしくみを
提供する。必要な手続きは、/lib/
の中に
libnss_winbind.so
を書き、次に適切な場所で
/etc/nsswitch.conf
に“winbind”を追加
するだけである。これで、Cライブラリは、Winbindを呼んでユーザー名や
グループ名を解決できるようになる。
PAMは、認証と認証技術を抽象化するものである。PAMモジュールを使用すると、 異なるシステムアプリケーション用にそれぞれ異なる認証方法を指定でき、 しかも、これらのアプリーケーションを再コンパイルする必要はない。 PAM はまた、特別なポリシーを認証に実装するためにも有用である。例えば、 システム管理者は、ローカルなパスワードファイルに格納されたユーザーからは コンソールログインのみを許可し、NISデータベースから解決されるユーザーに ついては、ネットワーク経由のログインを許可することができる。
Winbind は、認証管理とパスワード管理のPAMインタフェースを使用して、 Windows NTユーザーをUNIXシステムに統合する。これにより、 Windows NT ユーザーはUNIXマシンにログインでき、適切なPDCの認証を受けることが できるようになる。このようなユーザーはパスワードの変更もできる上、 その変更内容をPDCに直に反映させることができる。
PAMは、認証を必要とするサービスごとに、/etc/pam.d/
の
ディレクトリに管理ファイルを設けて設定する。アプリケーションが認証要求を
出すと、Cライブラリ内のPAMコードが、認証を行うために、どのモジュールを
どの順番でロードするべきかを決定するためにこの管理ファイルを検索する。
このインタフェースにより、Winbindに新しい認証サービスを追加することが
簡単になる。必要な手順は、/lib/security/
に
pam_winbind.so
モジュールをコピーすることと、
Winbind 経由の認証を可能にするために、関連するサービスのPAM管理ファイルを
更新することである。詳細は、
PAMベースの分散型認証のPAMの説明を参照のこと。
Windows NT/200xでユーザーまたはグループが作成されると、数字で構成される 相対ID(RID)を割り当てられる。これは、UNIXとは幾分異なる。UNIXでは、 ユーザーIDに使用される数字の範囲と、グループIDに使用される数字の範囲が 別々になっている。RIDをUNIXのIDに変換する、またはその逆を行うのが Winbindの仕事である。Winbindを設定する際、UNIXユーザーIDのスペースの 一部とUNIX グループIDのスペースの一部を、Windows NTのユーザーと グループを格納する場所である。Windows NTユーザーが最初に解決されるとき、 上記の範囲の中から次の空き番号をUNIX上のIDとして割り当てる。この 同じプロセスがWindows NTグループに対しても適用される。こうして一定の 時間が経つと、全てのWindows NTユーザーとグループはWinbindにより、対応 するUNIXユーザーIDとグループIDへマッピングされることになる。
このマッピングの結果は、tdbのデータベース内のIDマッピングデータベースに 一貫して格納されていく。これにより、RIDが一貫した方法でUNIXのIDに マッピングされていくことを確保している。
Active Directoryシステムは、数多くのユーザー名やグループ名の検索を発行 する。 これらの検索に係るネットワークの負担を軽減するため、Winbindは、 NTドメインコントローラーから供給されるSAM シーケンス番号に基づいて、 キャッシュに保存する。PDCから返されたユーザー情報やグループ情報は、 同じくPDCから返されたシーケンス番号と一緒に、Winbindによってキャッシュに 保存される。ユーザー情報やグループ情報が変更される度に、Windows NTは シーケンス番号を増やす。キャッシュに保存されたエントリが満了になる ときに、シーケンス番号をPDC からリクエストし、キャッシュのエントリの シーケンス番号と比較する。番号が一致しないときは、キャッシュに保存された 情報を捨て、PDCから直接更新情報をもらうように更新を行う。
この節では、Winbindを入手して使えるようにするまでの手順を説明する。WinbindはNTまたは Windows 200xの PDCを通して、Windowsのドメインユーザーにtelnetやftpのような通常のサービス と、Sambaの各種サービスのためのアクセス制御と認証管理の機能を提供することができる。
現在使用しているSamba設定ファイルがあるなら、バックアップを取ること!。
使用中のシステムが既にPAMを使用しているなら、
/etc/pam.d
ディレクトリの内容をバックアップすること!。
起動ディスクをまだ作成していないのなら今すぐに作ること!。
PAM設定ファイルを間違って修正すると、使用中のマシンにログインするのがほとんど不可能に
なってしまうことがある。このため、うまくいかない時にはマシンをシングルユーザーモードで
立ち上げ、/etc/pam.d
を元の状態に戻せるようにすること。
Samba-3の最新バージョンには、正常に機能する winbindd daemonが含まれている。ソースコードを ダウンロードする手順については、 Samba Webページか 最寄のSamba ミラーサイトにある説明を参照のこと。
ドメインユーザーがSambaの共有やファイルにアクセスできるようにし、また使用するマシンが 提供するその他のサービスにもアクセスできるようにするには、PAMを使用するマシン上で正しく 設定しなければならない。Winbindモジュールをコンパイルするには、PAM開発ライブラリを インストールすべきである。 PAMのウェブサイトを参照のこと。
開始する前に、使用しているサーバー上で走っている全てのSamba関連のデーモンを止めておくことを
推奨する。動いているかもしれないsmbd、nmbd、及びwinbinddの全プロセスを停止する。
PAMを使用するには、PAMを認識するサービスが使用するPAMモジュール、複数のPAMライブラリ、及び
PAMのための/usr/doc
と/usr/man
のエントリを含む、
/etc/pam.d
のディレクトリ構造を提供する、標準PAM パッケージを持って
いることを確認する。WinbindをSamba内で構築する際、pam-devel パッケージをインストールして
いると、よりうまくいく。このパッケージには、PAMを認識するアプリケーションをコンパイルする
のに必要なヘッダーファイルが含まれる。
PAMは、最新世代のUNIX/Linuxシステムの標準コンポーネントである。しかし、残念ながら
PAM対応のSambaを構築するのに必要なpam-devel
ライブラリをインストール
しているシステムは数が限られている。また、Samba-3はWinbindファイルを使用中のシステム上の
正しい位置に自動インストールするかもしれない。そこでこれ以上先に進む前に、以下に説明する
設定が本当に必要かどうか確認すること。もしかしたら、
/etc/nsswitch.conf
の設定だけで済むかもしれない。
winbindd daemonをnsswitch経由で走らせるために必要なライブラリを正しい場所にコピー しなければならない:
root#
cp ../samba/source/nsswitch/libnss_winbind.so /lib
また、以下のシンボリック・リンクを作成することが必要である:
root#
ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1
root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2
次に、rootになって、winbindd daemonからユーザーやグループのエントリが見えるように、
/etc/nsswitch.conf
を編集する。たとえば/etc/nsswitch.conf
ファイルを以下のように編集する:
passwd: files winbind shadow: files group: files winbind
winbindd
daemonが必要とするライブラリは、次回システムが再起動する
とき、自動的にldconfig
のキャッシュに入るが、手動で以下を行う方が
早い(それに、再起動する必要もない):
root#
/sbin/ldconfig -v | grep winbind
これにより、winbinddがlibnss_winbind
を使える状態になり、
dynamic link loaderによって使われる現在の検索パスを返す。ldconfig
コマンドの出力にgrep
フィルタを適用することで、このライブラリが
本当にdynamic link loaderによって認識されるかの確証を確認できる。
Sun Solarisのダイナミックリンクローダー管理ツールはcrle
と呼ばれる。
このツールは元々のOS環境の一部として提供されていないライブラリファイルを含む
ディレクトリを検索するよう指示するために必要である。以下の例は、ダイナミックリンク
ローダーの検索パスに、どのようにして/usr/local/lib
ディレクトリを
追加するために使うかを示す:
root#
crle -u -l /usr/lib:/usr/local/lib
引数なしで実行した場合、crle
は現在のダイナミックリンクローダーの
設定を表示する。それは以下の通り:
root#
crle
Configuration file [version 4]: /var/ld/ld.config
Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
Command line:
crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
これから、/usr/local/lib
ディレクトリは、オブジェクトモジュールの
依存関係を満足させるために、ダイナミックリンクライブラリの検索中に含まれていることが
わかる。
(この節はAIXを動作させている人にのみ関係する。)
Winbind AIX識別モジュールは、Sambaソースのnsswitchディレクトリ内に
libnss_winbind.so
として構築される。このファイルは、
/usr/lib/security
にコピーでき、AIXの名前変換から、WINBIND
という名前にするべきであると指示してくる。次の節では、以下のようにして、
WINBIND: program = /usr/lib/security/WINBIND options = authonly
/usr/lib/security/methods.cfg
が追加できるようなる。このモジュールは
識別のみサポートするが、標準のWinbind PAMモジュールを認証に使用して成功した例が報告されて
いる。ローダブルな認証モジュール設定の際には、システムにログオンできない状態になって
しまうこともあり得るので、慎重に行なうこと。AIX認証モジュールAPIに関する詳細情報は、
AIXのための、
Loadable Authentication Module Programming Interfaceで記述されている、
“Kernel Extensions and Device Support Programming Concepts for AIX”
という文書にある。モジュールの管理に関するさらなる情報は、
System
Management Guide: Operating System and Devicesにある。
winbinddの動作を制御するために、smb.conf
ファイルにいくつかのパラメーターを設定する必要が
ある。これについては、winbindd(8)マニュアルページに、より詳細に説明されている。
以下のWinbind設定のためのsmb.confによるsmb.conf
は、
[global]セクションの中の必要なエントリーも含むように変更したものである。
Example 24.1. Winbind設定のためのsmb.conf
ドメインセキュリティに関与するすべてのマシンはドメインのメンバーであるべきである。 これはPDCとすべてのBDCにも適用される。
ドメインへの参加手続きは、net rpc join
コマンドを使って行う。この
手続きは、MS DCE RPC経由で登録された(通常はPDC)ドメインコントローラーと通信を行う。これは、
もちろん、smbd
プロセスが対象のドメインコントローラー上で動作
していなければならないということである。それ自身のドメインに参加できるように、一時的に
PDCとしてSambaを起動することは、そのために必要である。
PDC
という名前のPDCで、ドメイン中で管理者権限を持つドメイン
ユーザーがAdministrator
である時、以下のコマンドを入力し、
Sambaサーバーをドメインに参加させる。
ドメインにマシンを参加させる前に、対象のドメインコントローラー(通常はPDC)でSambaが 動作しているかを確認し、ポート137/udp, 135/tcp, 139/tcp, と 445/tcpが開いているかを 確認する(もしもPDCがSambaかWindows Server 2Kxの場合)。
root#
/usr/local/samba/bin/net rpc join -S PDC -U Administrator
このコマンドへの正しい解答は、“Joined the domainDOMAIN
”
である。ここで、DOMAIN
は対象のドメイン名である。
最終的には、Sambaのその他の部分が立ち上がるときに、自動的にwinbindd daemonを呼び出す ように、Sambaの起動スクリプトを変更したいと思うかもしれないが、Winbind部分だけを最初に テストしておくことは可能である。Winbind のサービスを立ち上げるには、以下のコマンドを rootとして入力する:
root#
/usr/local/samba/sbin/winbindd
winbindd
実行ファイルの位置への適切なパスを使用すること。
上記は、/usr/local/samba
のディレクトリツリーの中にSamba を
インストールしたと仮定している。使用するシステム上でwinbindd
が別の
所にある場合は、Sambaファイルの位置を探す必要がある。
心配性な人の場合、daemonが本当に動いているかは以下で確認出来る。
root#
ps -ae | grep winbindd
このコマンドは、daemonが動いているなら、以下のような結果を返してくるはずである。
3025 ? 00:00:00 winbindd
次に、本当のテスト用に、PDC上にあるユーザー情報を取得する:
root#
/usr/local/samba/bin/wbinfo -u
これは、PDC上のWindowsユーザー情報に入っているユーザーの一覧をエコーバックするはずである。 例えば、以下のような結果が表示される:
CEO\Administrator CEO\burdell CEO\Guest CEO\jt-ad CEO\krbtgt CEO\TsInternetUser
もちろん、ドメイン名は“CEO”で、winbind separatorは “\”である。
root#
/usr/local/samba/bin/wbinfo -g
CEO\Domain Admins CEO\Domain Users CEO\Domain Guests CEO\Domain Computers CEO\Domain Controllers CEO\Cert Publishers CEO\Schema Admins CEO\Enterprise Admins CEO\Group Policy Creator Owners
ここで、getent
コマンドを使用して、ローカルとPDCの両方からユーザーと
グループの統合された一覧を表示させることができる。以下のコマンドを入力する:
root#
getent passwd
/etc/passwd
のような、ドメインユーザーの新しいUID、GID、
ホームディレクトリ及び既定値のシェルが表示される一覧が出てくるはずである。
グループについても同様に以下のコマンドを実行できる:
root#
getent group
winbindd daemonはsmbdとnmbd daemonが動き出してから起動する必要がある。これを
行うには起動スクリプトを書き換える。それは、Red Hat Linuxでは
/etc/init.d/samba
にあり、Debian Linuxでは
/etc/init.d/samba
にある。これらのdaemonを正しい順序で走らせる
ためのコマンドをスクリプトに加える。たとえば、起動スクリプトの例としては、
smbd, nmbd, と winbinddを直接/usr/local/samba/bin
ディレクトリ
から起動する。このスクリプト中のstart
関数は以下の通り:
start() { KIND="SMB" echo -n $"Starting $KIND services: " daemon /usr/local/samba/bin/smbd $SMBDOPTIONS RETVAL=$? echo KIND="NMB" echo -n $"Starting $KIND services: " daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS RETVAL2=$? echo KIND="Winbind" echo -n $"Starting $KIND services: " daemon /usr/local/samba/sbin/winbindd RETVAL3=$? echo [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ touch /var/lock/subsys/smb || RETVAL=1 return $RETVAL }
winbindd をデュアル・デーモン・モードで走らせたい場合は、上記例の中の:
daemon /usr/local/samba/sbin/winbindd
の列を、以下に変える:
daemon /usr/local/samba/sbin/winbindd -D
.
stop
関数は、サービスを停止するために以下のように起動に対応するエントリを持つ:
stop() { KIND="SMB" echo -n $"Shutting down $KIND services: " killproc smbd RETVAL=$? echo KIND="NMB" echo -n $"Shutting down $KIND services: " killproc nmbd RETVAL2=$? echo KIND="Winbind" echo -n $"Shutting down $KIND services: " killproc winbindd RETVAL3=$? [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ rm -f /var/lock/subsys/smb echo "" return $RETVAL }
WinbindはSolaris 9では動作しない。 see Solaris 9でのWinbindの節を参照のこと。 for details.
Solarisでは、/etc/init.d/samba.server
起動スクリプトを変更する必要が
ある。また、通常は smbd と nmbdのみを起動するが、winbinddも起動すべきである。Sambaが
/usr/local/samba/bin
にインストールされている場合、このファイルには
以下のようなものを含むことが出来る:
## ## samba.server ## if [ ! -d /usr/bin ] then # /usr がマウントされていない exit fi killproc() { # 名前指定でプロセスを停止 pid=`/usr/bin/ps -e | /usr/bin/grep -w $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` [ "$pid" != "" ] && kill $pid } # Sambaサーバーに必要な起動/停止プロセス case "$1" in 'start') # # 使用環境(パス、ワークグループ、ホスト)に合わせて以下を編集すること # echo Starting SMBD /usr/local/samba/bin/smbd -D -s \ /usr/local/samba/smb.conf echo Starting NMBD /usr/local/samba/bin/nmbd -D -l \ /usr/local/samba/var/log -s /usr/local/samba/smb.conf echo Starting Winbind Daemon /usr/local/samba/sbin/winbindd ;; 'stop') killproc nmbd killproc smbd killproc winbindd ;; *) echo "Usage: /etc/init.d/samba.server { start | stop }" ;; esac
繰り返すが、Winbindをデュアルdaemonモードで動かしたい場合、上記の:
/usr/local/samba/sbin/winbindd
の部分を、下記に変える:
/usr/local/samba/sbin/winbindd -D
ここまで来たということは、winbindd
とSambaが一緒に動作している状態に
なったと言うことである。Winbindを使用して、他のサービスに認証を提供できるようにしたい
場合は、この先を読み進めること。PAMの設定ファイルを、この手順の中で変更する必要が出て
くる(現在使っている/etc/pam.d
ファイルのバックアップを取っていない
ならば、今行うこと)。
他のサービスでwinbinddを使用するためのPAM モジュールが必要になる。このモジュールは、
以下のコマンドで、../source
ディレクトリから
../source/nsswitch
ディレクトリにコンパイルされる:
root#
make nsswitch/pam_winbind.so
pam_winbind.so
ファイルは、他のPAMセキュリティモジュールのある
場所にコピーしなければならない。Red Hat システムでは、/lib/security
というディレクトリである。Solaris では、PAMセキュリティモジュールは、
/usr/lib/security
に入る。
root#
cp ../samba/source/nsswitch/pam_winbind.so /lib/security
/etc/pam.d/samba
ファイルは変更する必要がない。このファイルはそのまま残す:
auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth
Winbindを認証サービスに使用できるように手を加えたその他のサービスは、コンソール上の通常
ログイン(またはターミナルセッション)、telnetログイン、それにftpサービスである。これらの
サービスを有効にするには、まず、/etc/xinetd.d
(または
/etc/inetd.conf
)の中のエントリを変更する必要があるかも知れない。
Red Hat Linux 7.1以降のバージョンは、新しい xinetd.d 構造を使用しており、この場合、
/etc/xinetd.d/telnet
と/etc/xinetd.d/wu-ftp
の中の文字列を
enable = no
から
enable = yes
に変更する必要がある。
ftpサービスを動作させるためには、既にサーバー上に存在するドメインユーザーのために、個別に
ディレクトリを用意するか、ホームディレクトリを全ドメインユーザー用の汎用ディレクトリに
変更する必要がある。これらは、smb.conf
のtemplate homedir
グローバルエントリで簡単に設定できる。
template homedir中のディレクトリは、自動的には生成されない! pam_mkhomedirか、あらかじめ当該ユーザーに対してディレクトリを作成しておくようにして、 固有のホームディレクトリを使ってUNIXにログインできるようにすること。
/etc/pam.d/ftp
ファイルは、/etc/pam.d/samba
ファイルと似たような形で、Winbindのftpアクセスを許可するように変更できる。変更後の
/etc/pam.d/ftp
ファイルは以下の通り:
auth required /lib/security/pam_listfile.so item=user sense=deny \ file=/etc/ftpusers onerr=succeed auth sufficient /lib/security/pam_winbind.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_shells.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth
/etc/pam.d/login
ファイルもほぼ同様に変更できる。以下のようになる:
auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_unix.so use_first_pass auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so
auth sufficient /lib/security/pam_winbind.so
を追加するが、それに加え
required pam_securetty.so
を加えることにより、ネットワーク上からのrootのログインを不許可とした。また、
sufficient /lib/security/pam_unix.so use_first_pass
行をwinbind.so
行の後に加え、パスワードからのプロンプトが二重表示される
問題を解消した。
/etc/pam.conf
の変更が必要である。ドメインユーザーがローカルにも
telnetでもログオンできるように変更する。以下が変更内容である。pam.conf
を要件に沿ってカスタマイズしてもよいが、最悪の場合、システムがほとんど起動不能になることが
あるので、変更内容に十分自信がある場合のみ変更すること。
# #ident "@(#)pam.conf 1.14 99/09/16 SMI" # # Copyright (c) 1996-1999, Sun Microsystems, Inc. # All Rights Reserved. # # PAMの設定 # # 認証管理 # login auth required /usr/lib/security/pam_winbind.so login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass # rlogin auth sufficient /usr/lib/security/pam_winbind.so rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # dtlogin auth sufficient /usr/lib/security/pam_winbind.so dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth sufficient /usr/lib/security/pam_winbind.so other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass # # アカウント管理 # login account sufficient /usr/lib/security/pam_winbind.so login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin account sufficient /usr/lib/security/pam_winbind.so dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 # other account sufficient /usr/lib/security/pam_winbind.so other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_unix.so.1 # # セッション管理 # other session required /usr/lib/security/$ISA/pam_unix.so.1 # # パスワード管理 # #other password sufficient /usr/lib/security/pam_winbind.so other password required /usr/lib/security/$ISA/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Kerberos V5 認証のサポート(Kerberosを使用するにはアンコメントすること) # #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
さらに、winbind.so
行の後にtry_first_pass
行を追加することで、パスワードからのプロンプトが二重表示される問題を解消する。
Sambaを再起動して、pam.confで設定したアプリケーションから接続してみる。
Winbindシステムは、NSSとPAM及び適切なMicrosoft RPCコールを使用することで、UNIXシステム 上のMicrosoft Windows NTドメインユーザーのシームレスな統合を可能にした。その結果、UNIXと NTの混在するネットワークを運用する管理コストの大幅削減が実現さた。
Winbindは、現在のリリース版には、幾つかの制約があり、これは将来の リリースで克服していきたいと考えている:
Winbindは、現行では、他のOSへの移植は可能だが、Linux、Solaris、AIX、 及びIRIXのOSでのみ使用可能である。このような移植を実現するには、移植先の OSのCライブラリが、NSSとPAMシステムをサポートしていることが要件となる。 NSSとPAMがUNIXベンダの間でサポートを得るようになってきたので、この二つの サポートは以前より一般的に見られるようになった。
Windows NT RIDからUNIX IDへのマッピングは、 アルゴリズムで決められる のではなく、マッピングされていないユーザーとグループをWinbindが目にした 順番に番号を振っていく。そのため、RIDとUNIX IDのマッピング情報を持つ ファイルが不良になったり壊れたりした場合、前と同じマッピングを再現 することは難しいかもしれない。
現行では、Winbind PAMのモジュールは、Windows NTユーザーに対して設定される ワークステーションのログオン時間などの制約を考慮しておらず、PDC が強制 するものと想定している。
いかなる状況でもwinbindd
が動作しているシステム上で
nscd
を動かさないこと。
もしもnscd
がUNIX/Linuxシステム上で動いている時、NSSWITCHが
正しく設定されていても、ファイルとディレクトリの管理のために、ドメインユーザーと
グループを解決することはできない。
“
smb.conf
ファイルは正しく設定した。
idmap uid = 12000と
idmap gid = 3000-3500を設定し、
winbind
を走らせている。以下を行うとすべてうまく行く。
”
root#
wbinfo -u
MIDEARTH\maryo MIDEARTH\jackb MIDEARTH\ameds ... MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain Users MIDEARTH\Domain Admins MIDEARTH\Domain Guests ... MIDEARTH\Accountsroot#
getent passwd
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash ... maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
“ ところが、以下のコマンドは失敗する: ”
root#
chown maryo a_file
chown: `maryo': invalid user
“ 気が変になりそうなのだが何がいけないのだろう? ”
前記の問題と同じである。使用しているシステムは、恐らくnscd
を動作させて
いるのだろう。システムを再起動ではなく一旦シャットダウンすれば、その後では、問題は解消して
いるだろう。
Table of Contents
この章では、ネットワークリソースアクセス制御を改善するためと、ユーザー環境を自動化する ためと、使用時の作業をより簡単にすることをしたいと思っているネットワーク管理者のための とても重要な周辺機器についての問題を記述する。
しばしば、作業中のネットワーク環境とより理解しているものの違いは、すべてをより協調させる 小分けの観点で最もよく測れる。すべてのネットワークソリューションの 重要な部分は、リモートからMicrosoft Windowsワークステーションを管理すること、リモートで Sambaサーバーにアクセスすること、より信頼出来るネットワーク操作の場面において手助けとなる 他の保守作業と同様の、カスタマイズしたログオンスクリプトを提供することである。
この章では、それらの各領域についての情報を提供する。それらはここにあり、他の章にはなく、 そのため、参照が容易である。
“どのようにしてユーザーマネージャとサーバーマネージャを手に入れたらよいのか?”
NT4 サーバーを購入する必要がないので、どのようにしてユーザー マネージャとサーバーマネージャを手に入れたらよいのか?
Microsoftは、Windows 9x/Meシステム上でインストールするための、
Nexus.exe
と呼ばれるバージョンのツールを配布している。ツールセット
には、以下が含まれている:
サーバーマネージャ
ドメイン用のユーザーマネージャ
イベントビューワ
Microsoftの Nexus から書庫ファイルをダウンロードする。
ドメインとサーバーマネージャ用の、Windows NT 4.0バージョン用の ユーザーマネージャは、Microsoftの via ftpにある。
自由に使えるものから、費用がかかるものまでの間で、数多くのリモートデスクトップ管理 ソリューションが存在する。黙ってみていてはいけない。最も費用がかかるソリューションは えてして最も効果的なものである。どの場合も、使用しているネットワーク環境で、どれが 最も良いツールかを、自分で結論づける必要がある。
以下の情報はSambaメーリングリストに、2003年4月3日 23:33:50(UTC+00:00)に投稿 されたものである。以下は若干修正(プライバシーの理由で投稿者の詳細を省略)して ある。完全な答えは、削除したいくつかのコメントを考慮して再構成してある。
“ PDCとしてネットワーク上で動いている、優れたなLinux/Sambaサーバーがある。 これに、ユーザーが外部からシステムにログイン出来るようにして、家や他の 国からデスクトップ状態を使えるようにする、リモートデスクトップ機能を 追加したい。 ”
“ これを達成する方法はあるだろうか?Windowsターミナルサーバーが必要だろうか? それを設定する必要があり、それはドメインのメンバーか、BDCあるいはPDCになる のだろうか?コンピュータがドメイン中にいる場合でも、Microsoft Windows XPを リモートログインにするようなhackはあるだろうか? ”
提供された回答: NoMachineから 提供されている新しい“NX”ソフトウェアを申し込む。
これは、VNC/RFBとrdesktop/RDBをその中に取り込んでいる、簡単に使える、 リモートXプロトコルを実装しているが、今まで使ったことがあるかもしれない 他のものよりもパフォーマンスがよい。
リモートXは別に新しいものではないが、これが成し遂げたものは、遅いmodem/ISDN 接続上でも十分に使えるくらいのスピードを出す、新しい圧縮方法とキャッシング 技術である。
イタリアで(公開の)Red Hatマシンに対して、負荷の高いインターネット接続で、 KDE konquerorのサムネイルプレビューを有効にして、“マウスを載せると” その時点でポップアップするようにしてテストしてみた。その内側(リモートX)の セッションで、Windows XPマシンへののrdesktopセッションを起動した。パフォーマンスを 測ってみたところ、最初に631750ポイントというスコアが出た。
NXは、TightVNC, rdesktopやromete Xという、その時点までに使っていた他の “純粋な”接続方法のどれよりも、ローカルLANよりも良いパフォーマンスを 出す。2つのノードを直接クロス接続するよりも速い。
リモートXアプリケーションから手元のマシンに対して、音を再生することも出来、 (イタリアにあるKDEセッションで動いている)NXウィンドウからMozillaメールソフトに “コピーアンドペーストを”する事も出来た。このソフトはとてもよく 動いている!
リモートコンピューティングに一時的な興味のみあるどなたにも、 NXを使って 見る事をお勧めする。
無料で使えるクライアントソフトウェアをダウンロードし(Red Hat、SuSE、Debianと Windows用がある)、起動し5分間使える(この時testdrive.nomachine.com上に実際の UNIXアカウントを割り当てるために、アカウントデータを送る必要がある)。
計画されている要点では、クラスターのノードとしてNXアプリケーションサーバーを 動かせるようになり、単にNXセッションをローカルに起動し、透過的に アプリケーションを動かせる(アプリケーションが他のNXノードで動いていたとしても、 同じウィンドウで表示されるために、最初のログインで使われていたのと同じように 動く。また、フルスクリーンでも動作でき、そのすぐにリモートログインしていることを 全く忘れてしまうだろう)。
最後に最も良いことを:すべての主要な圧縮とキャッシュ技術はGPLのもとでリリース され、何かに組み込もうと思う人誰にもそのソースコードが公開されている!これらの 技術はちゃんと動くが、コマンドラインのみから起動する(そして、完全に動作する リモートXセッションを起動し動かすために使うにはとても不便である)。
質問に対する回答は以下の通り:
ターミナルサーバーをインストールする必要はない。XPはRDPのサポートを内蔵している。
NXはCitrixよりも安価であり対抗できうる性能があり、おそらくより速い。
XPをハックする必要はない。それはちゃんと動く。
透過的にリモートからXPマシンにログイン出来(そして、ドメインに対する認証が 必要だとしても、接続時に何かを変更する必要はない)。
NXの主要な技術はすべてオープンソースでGPLでリリースされている。 (とても不便だが)無料で、コマンドラインで使う事が出来るが、お金を出せば、 便利な(商用の)NX GUIフロントエンドを買うことが出来る。
そのようなフロントエンドに対する、OSS/Free Softwareでの実装に、NoMachineは 自分自身に対する競合を意味しているのにもかかわらず、力を貸し、手助けを している(このような主旨を、LTSP、KDEとGNOME開発メーリングリストにも表明 している)。
リモートアクセスに対する他の解は、CendioによるThinLincである。
ThxnLincは、LinuxとSolarisベースで使える、SSH、TightVNC、NFSとPulseAudioのような 標準プロトコルをベースとしたターミナルサーバーである。
ThinLincは、LAN環境において組織におけるシンクライアント運用にも、狭帯域においても 使えるリモートから仕事をする人がセキュアなリモートアクセスを行うのにも使える。 ThinLincは、単一の同時アクセスするユーザーに対して自由に使える。
プロダクトはWindowsターミナルサーバーかCitrix環境のフロントエンドとしても、 Windows XPマシンのフロントエンドとしても使え、sshプロトコル経由で接続時の安全性を 確保している。クライアントはLinux(数多くのシンクライアント端末と同様すべてのLinux ディストリビューションをサポート)とWindows用がある。JavaベースのWebクライアントも 提供されている。
ThinLincはCendioのデモシステムに接続することで評価が出来る。下記を参照。 Cendio's web サイト testdrive センタ。
Cendiaは以下を含む、いくつかのオープンソースプロジェクトにおける主要な貢献者である。 TightVNC, PulseAudio , unfsd, Python と rdesktop.
固有のネットワーク設定環境を作成するための、いくつかの機会がある。
ログオンスクリプトなし。
すべてのユーザーに適用される、単純な汎用ログオンスクリプト。
ユーザー単位あるいはグループ単位の属性に適用する条件付きログオンスクリプトの使用。
固有のログオンスクリプトを作るための、NETLOGON共有に対する アクセス上の、Sambaのpreexecとpostexec機能を使用し、それを実行。
kixStartのようなツールのユーザー。
Sambaソースコードの中には2つのログオンスクリプト生成/実行ツールが含まれている。
examples
ディレクトリのgenlogon
と
ntlogon
サブディレクトリを参照。
以下のリストはgenlogonディレクトリからのものである。
#!/usr/bin/perl # # genlogon.pl # # Perl script to generate user logon scripts on the fly, when users # connect from a Windows client. This script should be called from # smb.conf with the %U, %G and %L parameters. I.e: # # root preexec = genlogon.pl %U %G %L # # The script generated will perform # the following: # # 1. Log the user connection to /var/log/samba/netlogon.log # 2. Set the PC's time to the Linux server time (which is maintained # daily to the National Institute of Standards Atomic clock on the # internet. # 3. Connect the user's home drive to H: (H for Home). # 4. Connect common drives that everyone uses. # 5. Connect group-specific drives for certain user groups. # 6. Connect user-specific drives for certain users. # 7. Connect network printers. # Log client connection #($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); open LOG, ">>/var/log/samba/netlogon.log"; print LOG "$mon/$mday/$year $hour:$min:$sec"; print LOG " - User $ARGV[0] logged into $ARGV[1]\n"; close LOG; # Start generating logon script open LOGON, ">/shared/netlogon/$ARGV[0].bat"; print LOGON "\@ECHO OFF\r\n"; # Connect shares just use by Software Development group if ($ARGV[1] eq "SOFTDEV" || $ARGV[0] eq "softdev") { print LOGON "NET USE M: \\\\$ARGV[2]\\SOURCE\r\n"; } # Connect shares just use by Technical Support staff if ($ARGV[1] eq "SUPPORT" || $ARGV[0] eq "support") { print LOGON "NET USE S: \\\\$ARGV[2]\\SUPPORT\r\n"; } # Connect shares just used by Administration staff If ($ARGV[1] eq "ADMIN" || $ARGV[0] eq "admin") { print LOGON "NET USE L: \\\\$ARGV[2]\\ADMIN\r\n"; print LOGON "NET USE K: \\\\$ARGV[2]\\MKTING\r\n"; } # Now connect Printers. We handle just two or three users a little # differently, because they are the exceptions that have desktop # printers on LPT1: - all other user's go to the LaserJet on the # server. if ($ARGV[0] eq 'jim' || $ARGV[0] eq 'yvonne') { print LOGON "NET USE LPT2: \\\\$ARGV[2]\\LJET3\r\n"; print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n"; } else { print LOGON "NET USE LPT1: \\\\$ARGV[2]\\LJET3\r\n"; print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n"; } # All done! Close the output file. close LOGON;
これらは、より精巧か、有用なログイン処理システムがそれらのサイトを確認する事を期待している:
時々、Samba共有リソースへの同時接続の数を制限することが必要な場合がある。 たとえば、ユーザー毎に1つのネットワークログインのみを、サイトが許可したいような 場合である。
Sambaのpreexec script
パラメーターはユーザー単位に1つの接続
のみを許可するのに使える。この方法は完全に安全性があるわけではなく、副作用が
あるかもしれない。以下の寄贈された方法はより良い解を誰かに思いつかさせて、
提供を促すかもしれない。
これは、Windowsクライアントが、実際にそうである間、共有をもう使っていないと
見える場合に、自動再接続機能を使って、アイドル状態の接続を切ってしまうことが
出来るという理由で完全な解ではない。そうだったとしても、これは、
preexec script
パラメーターの使用の原理的なデモである。
以下の共有設定は“Script to Enforce Single Resource Logon”中で示されるスクリプトの使用をデモする。
[myshare] ... preexec script = /sbin/PermitSingleLogon.sh preexec close = Yes ...
Example 25.1. Script to Enforce Single Resource Logon
#!/bin/bash IFS="-" RESULT=$(smbstatus -S -u $1 2> /dev/null | awk 'NF \ > 6 {print $1}' | sort | uniq -d) if [ "X${RESULT}" == X ]; then exit 0 else exit 1 fi
Table of Contents
この章では、Sambaメーリングリストの投稿者による、個人的な経験と知識に由来する知識の 現状について要約する。投稿された情報を再構築する前に、すべての効果に、与えられた情報 を検証することが行われた。この検証を通じては、追加の情報はカバーされていないので、 それも提供している。
Microsoft Windows NT 3.5が発表された時、ホットな新しい話題は、ユーザーとグループに対する グループポリシーの実装であった。次にMicrosoft Windows NT4が来て、いくつかのサイトがこの 機能を適用し始めた。どうやって知ったかって?数多くの“ドジな”(あるいは 間違った)管理者はそれを行い、解決のために助けを求めたからである。
Windows 2000とActive Directoryがリリースを待っている間、管理者はグループポリシーは すばらしいというメッセージを聞かされ続けた。グループポリシーにより管理コストの低減が 可能となり、確かに利用者にとってありがたい点もある。しかし、Windows 200xの Active Directory と GPO によるユーザーとコンピュータ管理機能の活用は遅々として 進まなかった。これは、2000年から2001年にかけてのSambaメーリングリストにおける 過去ログにおいて、GPOに関連した投稿や、GPOをSambaの環境でどのように複製するのかと いった投稿がほとんどなかったことからも明らかであった。
トラフィック量から判断すると、2002年中盤以降は、GPO は多くのサイトでデプロイメント(運用) の一部として普通に用いられるようになった。 本章では、ユーザーのデスクトップとネットワーク上のクライアントワークステーションの 自動制御を可能とするために用いることが可能な、テクニックと方法についておさらいする (記載する)。
Microsoft Windowsプラットフォーム配下、特にMicrosoft NT4とMicrosoft Windows 95の リリースに従ったものは、ドメインコントローラーのNETLOGON共有中に配置できるタイプの ファイルを作成することが可能である。クライアントがネットワークにログオンすると、 このファイルは読み取られ、その内容で、クライアントマシンのレジストリの変更を開始する。 このファイルはユーザー、ユーザーのグループかマシンに影響するレジストリを変更させる ことを許可する。
Microsoft Windows 9x/Meようには、このファイルはConfig.POL
と
しなければならず、ポリシーエディターとしてよく知られている
poledit.exe
というツールを使って作成できる。ポリシーエディターは
Windows 98インストール用CD-ROMで提供されているが、Microsoft Windows Meでは提供
されなくなった。Microsoft Windowsネットワーク管理者からのコメントによると、
これはMicrosoft Windows Me リソースキットに含まれるようになったとのこと。
Microsoft Windows NT4サーバー製品には、
配下に
システムポリシーエディターが含まれている。
Microsoft Windows NT4とその後のクライアント用に、このファイルは
NTConfig.POL
という名前にしなければならない。
Microsoft Windows 2000からは、Microsoft管理コンソールすなわちMMCが新たに導入された。 このツールは、ネットワークアクセスとセキュリティ管理方法に対して、永遠に 止めることのないマイクロソフト社の歩みの中から生まれた新しい潮流である。 マイクロソフト社の新製品や新技術が登場するたびに、以前の常識が覆され、複雑化したツールと 方法が新たに生み出されるように見える。 マイクロソフト社の立場からすると、MMCは進歩である。しかし、機能の進歩には 大きな代償が伴っているのだ。
ネットワークとシステムポリシーの設定に着手する前に、 Implementing Profiles and Policies in Windows NT 4.0 という、MicrosoftのWebサイトで提供されている文書を読むことを強く推奨する(訳注:現存しない)。 これらは、四で理解すべきである、古いものに対する大量の追加文書である。 “グループポリシー”をMicrosoftのWebサイト上で探してみること。
以下で説明するものは、いくつかの有用な注意事項に関する短い議論である。ここで提供される 情報は不完全であることを警告する。
Windows 9x/Meは以下でWindows 98のグループポリシーエディターを使ってグループ
プロファイルを作成する必要があるとする。これはオリジナルの完全なWindows 98
インストールCD-ROM配下のtools\reskit\netadmin\poledit
ディレクトリ中にある。プログラムの追加と削除機能を使ってこれをインストールし、
次に、Have Diskをクリックする。
ユーザーポリシーまたはマイドキュメント
などの位置を指定する
ポリシーファイルを作成するために、グループポリシーエディターを使う。次に、
[NETLOGON]
共有のrootに配置する必要がある、
Config.POL
というファイルにこれらの設定をセーブする。
もしもWindows98がSambaドメインにログオンするように設定されていたならば、これは
自動的にこのファイルを読み、ログオンしようとするマシンの、Windows 9x/Me
レジストリを更新する。
さらなる詳細はWindows98リソースキットの文書中で説明されている。
もしも、正しい手順を踏まない場合、時々Windows 9x/Meはレジストリの正当性を検査し、 各Windows 9x/Meマシンに格納されているレジストリのバックアップコピーから、その 設定をリストアする。そのため、時々、オリジナルの設定に戻ってしまうと言うことに 気がつくだろう。
グループポリシーを適用するために、Windows 9x/Me用のグループポリシーハンドラーを
インストールする。Windows 98 CD-ROMの
\tools\reskit\netadmin\poledit
を参照。
grouppol.inf
をダブルクリックして、Windows 9x/Meにグループ
ポリシーをインストールする。不幸にも、これはグループポリシーを使うWindows 98/Me
マシンすべてで行う必要がある。
ntconfig.pol
を作成あるいは編集するために、NT4サーバーには
同梱されているが、NTワークステーションには含まれていない、
poledit.exe
というNTサーバーポリシーエディターを使う必要がある。
NT4ワークステーションにもポリシーエディターはあるが、ドメインポリシーを作成する
のには適していない。さらに、Windows 95のポリシーエディターはNT4ワークステーション
あるいはサーバーにインストールできるが、NTクライアントではこれは動作しない。
しかし、NTサーバーからのファイルはNT4ワークステーション上でも問題なく動く。
poledit.exe
, common.adm
と
winnt.adm
を必要とする。2つの*.adm
ファイルをc:\winnt\inf
に配置するのは、プログラムが他の場所を
指定されない限り既定値で探しに行く場所であるので、都合がよい。このディレクトリは
通常“hidden”である。
Windows NTポリシーエディターは、Windows NT4.0のサービスパック3(とそれ以降)にも
同梱されている。servicepackname /x
を使ってファイルを
解凍する。たとえばサービスパック6aではNt4sp6ai.exe /x
である。ポリシーエディターpoledit.exe
と関連するテンプレート
ファイル (*.adm)が解凍される。office97用のテンプレートファイルとポリシーエディターの
コピーをダウンロードすることも可能である。他の場所としては、Microsoftから
ダウンロードできるZero Administration Kitがあげられる。
Windows NTpシステムポリシーは、NT4形式のドメイン中のメンバーである、ユーザー、 グループとコンピュータ(クライアントワークステーション)に指定するレジストリ パラメーターの設定が出来る。このようなポリシーファイルはMicrosoft Windows 200x/XP でも動作する。
Microsoft Windows 2000では、最近新たにNT4形式のポリシーと比べて上位互換の機能を 提供する、形式のグループポリシーを導入した。もちろん、ポリシーを作るツールは 異なり、それを実装するメカニズムはもっと改良されている。
古いNT4形式のレジストリベースポリシーは、Microsoft Windows 2000/XP GPO中では
管理用テンプレート(Administrative Templates)として
知られている。前者は種々のセキュリティ設定の設定機能、インターネット
エクスプローラーの設定の強制、ユーザーデスクトップ(スタートメニュー中に現れる
メニュー項目に設定されるのと同じようなマイドキュメント
ファイルの配置を含む)の変更と外観の切り替え(redirect)を含む。
追加の新しい機能は、特定のWindowsアプリケーションソフトを特定のユーザー/グループに
有効化する事を行うことである。
思い出してほしいが、NT4のポリシーファイルはNTConfig.POL
という名前で、ドメインコントローラー上のNETLOGON共有のルートに格納される。Windows NT4
ユーザーはユーザー名とパスワードを入力し、ログオンを行うドメイン名を選択する。ログオン
プロセス処理の間、クライアントマシンは、認証サーバー上のNETLOGON共有から
NTConfig.POL
を読み、このファイル中にある設定に従い、ローカルの
レジストリ値を変更する。
Windows 200x GPOは機能がたくさんある。これらは、NETLOGON共有には格納されないが、 一部はActive Directoryそれ自身にWindows200x ポリシーファイルとして格納され、 残りはSYSVOLフォルダーと呼ばれる共有(かつ複製される)ボリューム中に格納される。 このフォルダーはすべてのActive Directoryドメインコントローラー上に存在する。 Active Directoryそれ自身に格納される部分は、グループポリシーコンテナ(GPC)と 呼ばれ、SYSVOLと呼ばれる複製された共有中に格納されるものは、グループポリシー テンプレート(GPT)として知られる。
NT4クライアントでは、ポリシーファイルは読み取られるが、各ユーザーがネットワークに ログオンする時のみ実行される。Microsoft Windows 200xポリシーは、もっと 複雑である。GPOはクライアントマシン起動時(マシン固有の部分)で処理、 適用され、ユーザーがネットワークにログオンする時、ユーザー個別の部分が適用される。 Microsoft Windows 200x形式のポリシー管理では、各マシンあるいはユーザーは、 限りなく多くの、同時に適用可能な(かつ、適用される)ポリシーセット(GPO)の適用を 受けるかもしれない。NT4形式のポリシーファイルでは、これと同様の能力をもつものは 存在しない。
システムポリシーエディターというツールを使う代わりに、
通常はPoledit(バイナリファイルはpoledit.exe
)を使い、
以下のように、
Microsoftマネジメントコンソール(MMC)
スナップインを使って、GPOsの作成と管理を行う:
すべてのポリシー設定オプションはポリシー管理テンプレートを使用する ことによって制御される。NT4と同様Windows 200xでも、これらのファイルは 拡張子として.admを使う。しかしながら、.admファイルはNT4とWindows 200x 間で相互交換可能ではないことに注意。後者は拡張された定義を行えるような たくさんの新しい機能を導入している。どのように.admファイルをプログラム するかについて説明することは、この文書の範囲外である。それについては、 使用しているMicrosoft Windowsの、特定のバージョンに対する Microsoft Windowsリソースキットを参照のこと。
Microsoft Windows 2000リソースキットには、gpolmig.exe
というツールが入っている。このツールはNT4のNTConfig.POL
ファイルをWindows 200x形式のGPOに変換するのに使える。どのようにこの強力な
ツールを使うかについては十分に注意すること。特定の使用に関する情報については、
リソースキットのマニュアルを参照してほしい。
過去一年にわたって、Windows システムポリシーのための固有のテンプレートの 作成に関するいくつかの議論があった。Sambaメーリングリスト上での最近の 通知は言及に値する。
Mike Petersenは彼が作成したテンプレートファイルの有効性を通知した。この 固有のシステムポリシーエディターテンプレートは、SambaのようなSMBサーバーから Microsoft Windows ワークステーションを問題なく制御することができる。 このテンプレートは、いくつかのネットワーク上でテストされたが、 もしも、それらのポリシーについて何らかの問題を見つけたか、追加のポリシーに 関する何らかの案があったとしたら、mgpeter@pcc-services.comまでメールを 送って教えてほしい。このテンプレートはWindows XP用の数多くのポリシーを 含み、業務用の環境ではもっとよく動くようになっている。
さらなる情報については、 Petersen Computer Consulting Webサイトを参照してほしい。テンプレートファイルへの ダウンロードリンクがある。
ポリシーは、特定のユーザーの設定か、ユーザーのグループの設定を定義できる。結果のポリシー ファイルには、ポリシーファイルを使う、すべてのユーザー、グループとコンピュータ用の レジストリ設定が含まれる。各ユーザー、グループあるいはコンピュータ用にポリシーファイルを 分けることは不要である。
もしも、認証されたドメインコントローラーから自動的にダウンロードされるポリシーファイルを
作成したら、NTConfig.POL
と名前を付けるべきである。システム管理者には
ポリシーファイルの改名オプションがあり、Windows NTベースのワークステーションを
変更することで、マニュアルパス経由でポリシーファイルのするためにコンピュータを制御する。
手動でレジストリを変更するか、システムポリシーエディターを塚'ってこれを行うことが出来る。
これは、各マシンがその固有のポリシーファイルを持つようなローカルパスでも問題ないが、
もしも、すべてのマシンに対して変更が必要であれば、各ワークステーションに対して個別に
行わなければならない。
Windows NT4/200x/XPマシンがネットワークにログオンするとき、クライアントは、
NTConfig.POL
ファイルが存在するかどうかを、認証するドメイン
コントローラー上のNETLOGON共有中で捜す。もしも存在するならば、それをダウンロードし、
解析し、レジストリのユーザー部分に適用する。
Microsoft Windows Active DirectoryドメインにログオンするMicrosoft Windows 200x/XP
クライアントはActive Directoryそれ自身に定義され格納されるGPOを使って、さらに
ポリシーの設定を要求するかもしれない。ADのGPOを使う最も重要な利点は、
レジストリを汚染する効果がない言うことである。
これはNTConfig.POL
(NT4)形式のポリシー更新の使用と比較して
考慮すべき利点である。
さらに追加で、ユーザープロファイルと結合して動作する方法で、システムあるいは グループポリシー経由で、設定あるいは強制されるかもしれないアクセス制御の 追加においてMicrosoft Windows NT4/200x/XP下のユーザー管理環境は、ユーザー単位の アカウント制限が手cきょうされるのと同様に、ドメイン単位でもできる。 よく使われる共通の制限は以下のものがある:
ログオン時間
パスワードのエージング
特定のマシンからのログオンのみ許可
アカウントタイプ(ローカルまたはグローバル)
ユーザーの権限
Samba-3.0.20は、まだMicrosoft Windows NT4/200x/XPで共通なすべてのアカウント制御を実装
していない。Microsoft Windows NTp用のドメインユーザーマネージャを使って多くの制御を
設定する間、パスワード満了機能のみが現在使える。現時点で残りの制御の大半は、実際の
制御を提供するように、完了されるかもしれないダミーのルーチンである。NT4ドメイン
ユーザーマネージャを使うかNTConfig.POL
中でパラメーターが
設定できることから、誤解してはいけない。
グループポリシーを作成するか管理しようと思っている人は誰でも、いくつかのツールについて 慣れておく必要がある。以下の節では、余りメンテナンスをしないユーザー環境を作成するための 手助けとなる、主要なツールについて説明する。
editreg
と呼ばれる新しいツールが開発中である。このツールは、
ユーザーとグループプロファイル中に格納される(NTUser.DAT
と
呼ばれる)レジストリファイルを編集するのに使える。NTConfig.POL
ファイルはNTUser.DAT
ファイルと同じ構造を持ち、このツールを
使って編集できる。editreg
は、NTConfig.POL
ファイルをテキスト形式でセーブすることが出来るように意図し、拡張された機能を含む
新しいNTConfig.POL
ファイルを構築する事を出来るように作成されて
いる。この機能を実現するのは困難であることは分かっているので、もしもこの機能が
実現しなくとも驚かないでほしい。公に使える機能は、このツールの正式版がリリースされた
時に公開される。
以下は、システムの処理の順番と、システムの再起動とユーザーログオンの一部として処理される、 処理の順番を説明する試みである:
ネットワークが起動し、次にリモートプロシジャーコールシステムサービス(RPCSS)と multiple universal naming convention provider (MUP)が起動する。
Active Directory を使う場合、GPOの整列された一覧がダウンロードされて適用される。 リストは以下のGPOを含んでいても余韻
ディレクトリ中のマシンの配置を適用(Apply to the location of machines in a directory)。
設定が変更されたときのみ適用(Apply only when settings have changed)。
適用範囲の設定に依存:local,site,domain,organizational unitなど。
どのデスクトップユーザーインタフェースも、上記が処理されるまで提供されない。
スタートアップスクリプトの実行(既定値ではhiddenとsynchronous)。
ログオンを行うためのキーボード操作(Ctrl-Alt-Del)。
ユーザーの認証情報が検証され、ユーザープロファイルがロードされる(ポリシー設定に依存)。
ユーザーGPOの整列された一覧を入手する。一覧の内容は、以下の点で何が含まれているかに依存する:
ユーザーがドメインのメンバーか、結果、特別なポリシーの適用を受けるか?
Loopback enablement, and the state of the loopback policy (併合または置換)。
Active Directoryそれ自身の位置
GPOの一覧が変更されたか?もしも変更されていないならば、処理は不要である。
Active Directoryからのユーザーポリシーが適用される。注意:いくつか種類がある。
ログオンスクリプトが動く。Windows 200xとActive Directoryから新規に、ログオン スクリプトはGPOをベースにして得られるかもしれない(hiddenとsynchronouslyに実行)。 NT4形式のログオンスクリプトは通常のウィンドウで動作する。
GPOから決定されたユーザーインタフェースが提供される。注意:Sambaドメイン中では (NT4ドメインのように)、マシン(システム)ポリシーは起動時に適用される。 ユーザーポリシーはログオン時に適用される。
ポリシーに関連する問題は、診断するのがとても難しく、さらに修正するのがもっと難しい 可能性がある。以下の項目は、基本的な問題のみを示している。
“Config.POL
ファイルを作成し、NETLOGON
共有に置いた。が、Windows XP Proマシンでは、それが見えていないような感じで、何ら
違いがなかった。Windows 98では正しく動作したが、Windows XP Proにアップグレードして
からはもはや動かなくなった。何かヒントはないか?”
ポリシーファイルはWindows 9x/MeとMicrosoft Windows NT4/200x/XPベースのプラットフォーム
の間では互換性がない。NTConfig.POL
というファイルをNT4の
グループポリシーエディターで作成する必要があり、そうすると、Microsoft Windows XP Pro
クライアント用の正しい形式になる。
移動プロファイルは一部の人にとっては恐れられており、 これを忌み嫌う人もいないではないが、また多くの人に愛されてもいる。 これを天の恵みだと考えている管理者もいる。
ユーザーが使用するマシンを毎回変えるような環境であっても、ローミング プロファイルを使えば管理者は常に同じユーザーデスクトップ環境を提供できる。 この章では移動プロファイルの構成と管理の手法に関する多くの情報を 提供する。
移動プロファイルはある種、楽園のように聞こえる人もいるかも しれないが、その他の人々にとっては、これは現実の、そして目に見える 問題でもある。特に、接続状態が安定しないモバイルコンピューティング 機器を利用するユーザーは、純粋なローカルプロファイルを使うケースが 多いであろう。この章では Samba の管理者がこのような状況に対処する ための手助けになるような情報を提供する。
移動プロファイルのサポートは、Windows 9x/Me と Windows NT4/200x でそれぞれ異なる。
移動プロファイルの構成方法について論じるのに先立って、 Windows 9x/Me と Windows NT4/200x クライアントが、それぞれどのように これらの機能を実装しているのかを知ることもまた有用であろう。
Windows 9x/Me クライアントは NetUserGetInfo リクエストをサーバーに送り、 ユーザープロファイルの場所を取得する。しかしながら、その応答の中には 分割されたプロファイルの位置を保持するためのフィールドを格納する領域はなく、 単にそのユーザーの home 共有が渡されるだけである。つまり、Windows 9x/Me のプロファイルでは、プロファイルをユーザーのホームディレクトリーに格納する ことしかできない。
Windows NT4/200x クライアントは NetSAMLogon RPC リクエストを送る。 これには多くのフィールドがあり、分割されたユーザープロファイルの位置を表す 情報も含まれている。
この章では MS Windows クライアントのプロファイルサポートのための Samba の設定について解説する。
たとえば、Windows NT4/200x をサポートする場合、以下の設定を
smb.conf
ファイルの [global] セクションに書けばよい。
logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath |
これは一般に以下のような実装を表している:
logon path = \\%L\Profiles\%U |
ここで“%L”は Samba サーバーの名前に置き換えられ、 “%U”はユーザー名に置き換えられる。
このオプションのデフォルトは \\%N\%U\profile
すなわち \\sambaserver\username\profile
である。
\\%N\%U
サービスは [homes] サービスにより
自動的に生成される。Samba サーバー経由でプロファイルを使う場合は、
logon path で指定された共有をブラウズ可能にしておかなければならない。
“%L” と “%N” の違いや “%U” と
“%u” の違いについては smb.conf
の man ページを参照してほしい。
Windows 9x/Me クライアントをサポートするには、
logon homeパラメーターを使用すること。
Sambaが修正され、logon home
パラメーターを信頼
するnet use /home
も動作するようになった。
logon home
パラメーターを指定すると Windows 9x/Me
のプロファイルの格納位置はユーザーのホームディレクトリーに制限される。
しかし待って欲しい。実はこれは裏技的なやり方である。smb.conf
ファイルの
[global]
セクションに
logon home = \\%L\%U\.profiles |
を記載すると、Windows 9x/Me クライアントはちゃんと自分のプロファイルを
ホームディレクトリー配下の .profiles
という隠し
ディレクトリーに正しく保存するようになる。
これだけではなく、net use /home
は Windows 9x/Me
における機能のためにもなる。これはホームディレクトリーにあるすべての
ディレクトリーを削除し、サーバーと共有部分のみを使用する。すなわち、
あたかも logon home に
\\%L\%U
を指定したように振舞う。
logon home とlogon path 両方のパラメーターをセットすると、Windows 9x と Windows NT クライアントの 両方をサポートできるようになる。たとえば、
logon home = \\%L\%U\.profiles |
logon path = \\%L\profiles\%U |
Windows 9x/Me と NT4 およびそれより新しいプロファイルは、同じ位置に 格納するべきではない。なぜなら、Windows NT4 とそれ以降のクライアントは プロファイルが混在した環境で問題を起こすからである。
しばしば行われる質問として、“強制的にローカルプロファイルにするには? ”や“どうやったら移動プロファイルを無効にできるか?” といったものがある。
smb.conf
においてlogon home = および logon path = を適用すると、すべてのクライアントがローカルプロファイルを使うようになる。
これらのパラメーターへの引数はブランクのままにしておかなければならない。
空の値を設定する場合でも =
記号は必要である。
マイクロソフト管理コンソール(MMC)の gpedit.msc
を使って、その Windows XP マシンがローカルプロファイルだけを使う
ようにする。もちろんこれはレジストリの設定を変更する。
オプションへのフルパスは以下の通り:
ローカル・コンピュータ・ポリシー\ コンピュータの構成\ 管理用テンプレート\ システム\ ユーザープロファイル\ 無効: ローカルユーザープロファイルのみを許可する 無効: 移動プロファイルへの変更をサーバーに伝達しない
スタートメニューのマイコンピュータ・アイコンで右クリックし、 ユーザープロファイルの設定で変更したいプロファイルを 選んで「種類の変更」をクリックし、 を に変更する。
の詳細設定タブを開く。特定バージョンの MS Windows において、どのレジストリキーを変更すれば 強制的にローカルプロファイルになるのかは、MS Windows レジストリガイドを 参照のこと。
ユーザーが最初に Windows 9x にログインすると、user.DAT ファイルが生成される。
その中には スタートメニュー
,
デスクトップ
, プログラム
,
近くのコンピュータ
というフォルダーが入る。
二度目以降のログイン時は、これらのディレクトリーとその中身が
マージされて c:\windows\profiles\ユーザー名
に格納される。
これらにはそれぞれ最新の情報が入る。
ここで、プロファイルフォルダー内のショートカットを常に大文字で見せるために
[global]
オプションを、それぞれ
preserve case = yes,
short preserve case = yes,
and case sensitive = no
のように設定する必要がある。
user.DAT
ファイルにはそれぞれのユーザーの設定項目が
入っている。これらの設定を強制したい場合は、それぞれの
user.DAT
ファイルを user.MAN
にリネームし、さらにこれらのファイルを書き込み禁止にしておく。
Windows 9x/Me マシンでは、ユーザー・プロファイルタブを選ぶ。 要求する移動設定のレベルを選択して を押すが、 ここではコンピュータのリブートを行わない。
-> に入ってWindows 9x/Me マシンでは、Preferencesに行き、 NTドメインにログオンを選択する。 そしてプライマリログオン(通常のログオン方法?)が になっていることを確認して を押す。 ここでコンピュータをリブートする。
-> -> ->Windows 9x/Me では、プロファイルはプライマリ・ログオンからダウンロードされる。 プライマリ・ログオンが“ノベルネットワーク用クライアント” になっている場合、プロファイルとログオンスクリプトは使用中のノベルサーバー からダウンロードされる。プライマリ・ログオンが“Windows ログオン” になっている場合、プロファイルは移動プロファイルの考え方から少しはずれて ローカルマシンの からロードされる。
マイクロソフトネットワークのログインダイアログには
[ユーザー名, パスワード]
だけに代わって
[ユーザー名, パスワード, ドメイン]
が表示されている
ことにお気づきだろうか?ここで Samba サーバーのドメイン名、および
ユーザー名、パスワードを入力する。なお、Samba サーバーの代わりに
存在することがわかっているドメイン名を入力してもよい。その場合、
そのドメインによってユーザー認証が行われ、さらにそのドメインの
ログオンサーバーがサポートしていれば、プロファイルがそのサーバーから
ダウンロードされる。
そのユーザーの正当性が確認されると、Windows 9x/Me マシンは
このユーザーは過去に一度もログインされていません
を表示し、このユーザーの設定情報を保存しますか?
と聞いてくるので で答える。
Windows 9x/Me のデスクトップが起動したら、Samba サーバー上の
logon path にあるディレクトリーの中に
デスクトップ
, スタートメニュー
,
プログラム
, 近くのコンピュータNethood
フォルダー群が作られていることがわかるだろう。
これらのフォルダーはクライアント上でローカルでキャッシュされ、 (事前にリードオンリーに設定しておかない限り)ユーザーのログオフ時に更新される。 ユーザーがさらにフォルダーやショートカットを作ると、クライアントはこれらを すでにダウンロード済みのプロファイルの中身とマージして、それらの中から 最新のフォルダーやショートカットを選択する。
Samba サーバー上のフォルダー/ファイルをリードオンリーにしていた場合、 Windows 9x/Me はログオンやログアウト時にローカルとリモートの プロファイルをマージしようとしてエラーが発生する。基本的に Windows 9x/Me でエラーが出たら、Samba サーバー上のプロファイルディレクトリーで、 UNIX 側のファイルのパーミッションや所有者の権限をチェックしてみてほしい。
ユーザープロファイルの生成で失敗する場合、そのユーザーのローカルデスクトップの キャッシュを後述の要領でリセットしてやるとよい。このユーザーが次回ログオンした時、 “今回はじめて”ログオンした旨のメッセージが表示される。
[ユーザー名, パスワード, ドメイン] ダイアログでログオンする代わりに
を押す。
regedit.exe
を起動して以下のエントリを探す:
HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
ここに各ユーザーの ProfilePath があるので(このキーの内容は
c:\windows\profiles\ユーザー名
と同様である)、この中で
該当するユーザーの ProfilePath
キーを削除する。
レジストリエディターを終了する。
c:\windows
ディレクトリー配下から当該ユーザーの
パスワードチェインファイル .PWL を見つけ、これを削除する。
Windows 9x/Me クライアントをログオフする。
プロファイルパスの中身(前述の logon path
を参照)を確認し、ユーザーの user.DAT
または
user.MAN
を、必要であればバックアップを取ってから
削除する。
ProfilePath
(おそらく
c:\windows\profiles\username
)の一覧にあるディレクトリーの
中身を削除する前に、各ユーザーのデスクトップやスタートメニューに重要なファイルが
ないかどうかを確認しておく。ProfilePath
ディレクトリーの
中身を(必要であればバックアップを取ってから)削除する。
これで、各ユーザーのプロファイルディレクトリーにある(それぞれが
リードオンリーでかつ隠しファイル、システムファイルである)ローカルの
user.DAT
, “desktop”,
“nethood”, “start menu”, “programs”
といったフォルダーが削除される。
八方手を尽くしてもだめなら、Samba のログレベルを 3 から 10 まで増やしてみて、
さらに ethereal や netmon.exe
といったコマンドでパケット
をキャプチャしてエラーメッセージ等を捕捉してみる。
Windows NT4/200x サーバーへのアクセス権を持っている場合は、まず Windows NT4/200x サーバー上で移動プロファイルや netlogon の設定を行う。 その後 Windows NT4/200x サーバーが吐きだすパケットを解析して、 Samba のトレース結果と照合し、何が違うのかを調べてみる。
ユーザーが最初に Windows NT workstation にログインした時、NTuser.DAT というプロファイルが生成される。プロファイルの場所は logon path パラメーターで指定できる。
現在は、NT プロファイルを利用可能にするための
logon drive というパラメーターもある。
これは H:
もしくは他のドライブ名に向けておき、
また logon home パラメーターと組み合わせて使用する。
NT4 プロファイルのエントリはファイルではなくディレクトリーである。 プロファイルに関する NT のヘルプによれば、.PDS という拡張子を持つ ディレクトリーが同時に作られるらしい。ログイン時、当該ユーザーは完全な プロファイルパス(および、.PDS 拡張子を持つディレクトリーが作られる のでそれも)を作るための書き込み権が必要である。
Windows NT4 では、プロファイルディレクトリーに Windows 9x/Me で作られる
デスクトップ
,
ネットワークコンピュータ
,
スタートメニュー
,
プログラム
以外に
アプリケーションデータ
フォルダーが作られる。
プロファイル自体は NTuser.DAT
ファイルに格納される。
.PDS ディレクトリには何も書き込まれないようで、現時点でここの目的は謎である。
システム コントロール パネル を使って
ローカルプロファイルを Samba サーバーにコピーすることができる
(プロファイルに関する NT のヘルプを参照のこと:さらに、これで
システム コントロール パネルの中で
正確な位置を確認することもできる)。NT のヘルプによれば、残りの
NTuser.DAT
から NTuser.MAN
は、
プロファイルを強制するためのものであるらしい。
プロファイル名の大文字小文字は重要である。このファイル名は
NTuser.DAT
、強制用ファイルであれば
NTuser.MAN
でなければならない。
まずローカルプロファイルを MS Windows ワークステーション上で 以下のようにドメインプロファイルに変換しなければならない:
ローカルのワークステーション管理者 としてログイン
マイコンピュータアイコンで 右クリックして を選択
ユーザープロファイルタブをクリック
変換したいプロファイルを選択(一回クリック)
ボタンをクリック
使用を許可するユーザー/グループ ボックスの ボタンをクリック
マシン名の一覧が出る場所をクリック。 ここをクリックすると選択ボックスが開くので、プロファイルを アクセス可能にするべきドメインをクリック。
ログオンボックスが表示された場合はそこでログオンする。
たとえば DOMAIN
\root に
パスワード:mypassword
で接続する。
プロファイルを誰でも使えるようにする場合は “Everyone” を選択
を押すと選択ボックスが閉じる
これで
を押すと、 指定した場所にプロファイルが作られる
これで Samba の profiles
ツールから編集可能な
プロファイルの作成ができた。
Windows NT/200x では、必須プロファイルを使うとメールデータとして MS Exchange のストレージを使うことしかできなくなり、またこれは デスクトッププロファイルからは除外される。これにより、 デスクトッププロファイルを使用不可にできない。
Windows XP (もしくは Windows XP サービスパック 1 のみ?)では セキュリティーチェックが追加された。これは Active Directory のグループポリシー経由で無効にできる。このポリシーは、以下の 手順で呼び出せる:
コンピュータの設定\ 管理用テンプレート\ システム\ ユーザープロファイル\ 移動プロファイルフォルダーのユーザー所有権を確認しない
これは 有効
にしておく
新しいバージョンの Samba には Active Directory と似たような 仕組みがあるだろうか?もしあるなら、前述の手順に従って このポリシーを設定できるだろう。
Samba ではグループポリシーが設定できないようでも、各マシンで ローカルに設定することは可能である。もしこの作業を行いたければ 以下のようにすればよい:
XP workstation に管理者権限でログインする
-> をクリック
mmc
とタイプする
をクリック
マイクロソフト管理コンソールが起動する
-> -> をクリック
グループポリシーをダブルクリック
-> をクリック
をクリック
“コンソールルート” ウィンドウで ローカルコンピュータポリシー -> コンピュータの構成 -> 管理用テンプレート -> システム -> ユーザープロファイルを展開
移動プロファイルフォルダーのユーザー所有権を確認しない をダブルクリック
有効を選択
をクリック
コンソール全体を閉じる。設定を保存する必要はない (「保存」は変更したポリシーのことでではなく、コンソール設定の ことを指している)
リブート
終了時に、移動プロファイルのキャッシュされたローカルコピーを強制削除する
設定になっているにも関わらず、それらが消されないという状況がありうる。
このような現象に対処するために、特別なサービスが作られた。
Windows NT4/2000/XP Professional と Windows 2003 には
UPHClean
(User Profile Hive Cleanup) という
アプリケーションをサービスとしてインストールできる。
UPHClean のソフトウェアパッケージは the User Profile Hive Cleanup Service[7]というWebサイトからダウンロードできる。
Windows の異なったバージョン間でデスクトップを共有することは推奨されない。 デスクトッププロファイル領域は未だ進化の途上であり、新しいバージョンの Windows プロファイルで追加された機能は、それまでのバージョンの動作を 阻害する。新旧のプロファイルを混在させるべきではないより大きな理由は、 古いバージョンの Windows をログオフする際、古いフォーマットを持つ プロファイルの中身が新しいバージョンに属する情報を上書きしてしまい、 結果的にユーザーが新しいバージョンの Windows でログオンし直した際に必要な プロファイル情報が失われてしまうからである。
Windows 9x/Me とスタートメニューやデスクトップを共有させたい場合は、
プロファイルの共通領域を指定してやらなければならない。smb.conf
で
同じにしなければならないパラメーターは logon path
と logon homeである。
これらが正しく設定されていれば、同じプロファイルディレクトリの中に別々の
user.DAT
と NTuser.DAT
ファイルが見えるはずである。
ユーザープロファイルの位置に関しては、どこのパスを指定してもよい。つまり プロファイルを保存する場所は、その SMB サーバーが暗号化パスワードを サポートしている限り、Samba サーバーでもそれ以外のその SMBサーバー でもかまわない。
残念なことに、現在のリソースキットの情報は Windows NT4/200x に特化 したものとなっている。各プラットフォームに対応したリソースキットの 存在が望まれる。
クイックガイド
Procedure 27.1. プロファイルの移行手順
NT4 のドメインコントローラーの マイコンピュータで右クリックして プロパティ の ユーザープロファイル タブを選ぶ
移行したいユーザープロファイルを選んでクリック
ここでご紹介するのはゆるやかな“移行”
方法である。プロファイルをコピーしてグループプロファイルを作成し、
このプロファイルへのアクセス権を Everyone
ユーザーに与える。Samba ドメインが NT4 の PDC と信頼関係を結んでいない
場合は、単にこれだけでよい。
ボタンをクリック
プロファイルのコピー先ボックスで、
c:\temp\foobar
のように新しいパスを追加する
使用を許可するユーザー/グループ ボックスの をクリック
グループ“Everyone”をクリックし、 をクリック。これで“ユーザーを選択” ボックスが閉じられる
これで
をクリック全てのプロファイル移行について、以下の手順に従う。
NT4 ドメイン側の SID を取得するには
net rpc info
コマンドが使える。詳細は
The Net Command Chapter,
Other Miscellaneous Operations
を参照されたい。
Windows 200x のリソースキットには moveuser.exe
が含まれる。moveuser.exe
はあるプロファイルの
セキュリティをあるユーザーから別のユーザーに変更する。これにより
アカウントのドメインを変更したりユーザー名を変更したりできる。
このコマンドは Samba のprofiles
コマンドの
ようなものである。
Windows NT Server 4.0 のリソースキットに含まれる
GetSID.exe
を使って SID を取得できる。
Windows NT 4.0 ではローカルプロファイルの情報はレジストリキー
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
配下に格納される。
ProfileList キー配下には、現在このコンピュータにログオンしている
ユーザーが、SID をサブキー名として格納されている。
(ローカルにキャッシュされているプロファイルから移動したいユーザーの
プロファイル情報を見つけるには、GetSID.exe
ユーティリティーでこのユーザーの SID を見つければよい)。
適切なユーザーのサブキーの中に
ProfileImagePath
という名前の文字列値があるはずである。
必須プロファイルとは、ユーザーが上書きできないプロファイルのことである。 ユーザーセッションが有効の間、デスクトップ環境の変更が可能である。 しかしながら、ユーザーがログアウトするとすべての変更内容は失われてしまう。 ユーザーにデスクトップ環境を変更させたくない場合は、この設定をポリシー 設定を通して行うことができる。 System and Account Policies を参照のこと。
どのような状況においてもプロファイルディレクトリー(もしくはそのファイル)
をリードオンリーにはできない。なぜならそのプロファイルが使用できなく
なってしまうからである。ただし UNIX ファイルシステム配下であれば
プロファイルをリードオンリーにできなくもない。この場合、
fake-permissions
VFS モジュールを使用する必要がある。
これは Windows NT/200x/XP クライアントに対して、そのユーザーのプロファイルに
書き込み権があるようにふるまう。
fake_perms VFS module
を参照のこと。
Windows NT4/200x/XP では、必須プロファイルを作るのに
Windows NT4/200x サーバーから Samba
へのプロファイルの移行にあるような手順が使える。
グループプロファイルを必須プロファイルに変換するには、単に
コピー先にプロファイルにNTUser.DAT
ファイルを
入れ、それをNTUser.MAN
にリネームすればよい。
Windows 9x/Me の場合はUser.DAT
ファイルを
User.MAN
にリネームすることで必須プロファイルを
作成できる。
多くの組織は部署に分かれている。ひとつの部署内のユーザーは同じデスクトップ アプリケーションや同じデスクトップレイアウトを要求することが多いので、 部署単位で管理できるといろいろと都合のよいことが多い。 Windows NT4/200x/XP では、グループプロファイルが利用できる。 グループプロファイルは、まずテンプレート(例示)ユーザーを使って作られる。 その後、後述のプロファイル移行ツールを使ってそのユーザーグループから グループプロファイルに対する必要なアクセス権が設定される。
次のステップはもっと重要である。グループプロファイルを (ユーザーマネージャーを使って)各ユーザーに“ユーザー単位で” 割り当てるのではなく、そのグループ自体を更新されたプロファイルに 割り当てるのである。
グループプロファイルには注意すること。個人プロファイルをすでに持っている グループのメンバーがユーザーである場合、その結果は2つを統合(マージ) したものとなる。
Windows 9x/Me および NT4/200x/XP では、プロファイルが存在しないユーザー についてはデフォルトプロファイルを使用する。デフォルトプロファイルが Windows workstation 上にあるとわかっている場合、およびデフォルト プロファイルを作るパスを示すレジストリキーがわかっている場合、使用する デフォルトプロファイルをこのサイト用に最適化されたものに変更できる。 これは管理上重要な利点である。
Windows 9x/Me でユーザーごとのデフォルトプロファイルを有効にするには、 Windows 98 システムポリシーエディター を使うか、またはレジストリを直接変更する。
Windows 9x/Me でユーザーごとのデフォルトプロファイルを有効にするには システムポリシーエディターを起動し、 -> を選択する。次にローカルコンピュータアイコンを クリックし、Windows 98 システムをクリックして 「有効」ボックスのユーザープロファイルを選択する。 レジストリの変更を保存するのを忘れないこと。
レジストリを直接変更するには
レジストリーエディター
(regedit.exe
) を起動し、
HKEY_LOCAL_MACHINE\Network\Logon
ハイブを選択する。
ここで“User Profiles”キーのところに DWORD を追加する。
ユーザープロファイルを有効にするには 1 を、無効にするには 0 をセットする。
ユーザーが Windows 9x/Me マシンにログオンすると、そのユーザーに関する
既存のエントリを処置するのにローカルプロファイルのパス
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProfileList
がチェックされる。
レジストリのこの位置にユーザーのエントリがある場合、Windows 9x/Me は ユーザープロファイルのキャッシュされたバージョンをローカルでチェックする。 Windows 9x/Me では、さらにサーバー上にあるユーザーのホームディレクトリー (場所が変更されている場合は指定されたディレクトリー)にある(かもしれない) ユーザープロファイルもチェックする。プロファイルがどちらにもある場合は、 新しい方が使われる。プロファイルがサーバー上にあるがローカルマシン上には ない場合は、サーバー上のプロファイルをダウンロードして使用する。ユーザー プロファイルがローカルマシン上のみにある場合は、そのコピーが使われる。
ユーザープロファイルがこれらのどちらにもない場合は、Windows 9x/Me マシン のデフォルトユーザープロファイルが使われ、ログインしているユーザーの新しく 作られたディレクトリにこのプロファイルのコピーが作られる。ログオフの際、 ユーザーが行った変更がすべてこのユーザーのローカルプロファイルに書きこまれる。 このユーザーが移動プロファイルを使っている場合、変更内容はサーバー上ある このユーザーのプロファイルに書きこまれる。
Windows NT4 の場合、デフォルトユーザープロファイルは
%SystemRoot%\Profiles
から読みこまれる。
インストール時のデフォルト設定では、ここは
C:\Windows NT\Profiles
となる。
クリーンインストール後におけるこのディレクトリの中身は
Administrator
, All Users
,
Default User
という3つのディレクトリから構成される。
All Users
ディレクトリにはシステムユーザーすべてで
共通で使われるメニュー設定が入る。Default User
ディレクトリには、各ユーザーが自分で選択したり作成したりした
プロファイル設定に依存する、カスタマイズ可能なメニューエントリが入る。
新しいユーザーが最初に Windows NT4 のマシンにログオンする際、以下を元に 新しいプロファイルが作られる。
All Users の設定
Default User(デフォルトの
NTUser.DAT
ファイルを含む)の設定
あるユーザーがマイクロソフトのセキュリティードメインのメンバーである Windows NT4 マシンにログオンする際は、プロファイルの扱いに関して以下の 手順を踏む:
ログオンプロセスを通して得られるユーザーのアカウント情報には、その
ユーザーのデスクトッププロファイルの場所も入っている。プロファイルの
パスはマシンのローカルにある場合もあるし、ネットワーク共有の中かも
しれない。プロファイルがユーザーアカウントから得られたパスの位置に
ある場合、このプロファイルは
%SystemRoot%\Profiles\%USERNAME%
という位置にコピーされる。そしてこのプロファイルの内容は、
%SystemRoot%\Profiles
にある
All Users
プロファイルの設定を継承する。
ユーザーアカウントがプロファイルへのパスを持っているが、そこに
プロファイルが存在しない場合、Default User
プロファイルが参照され、それを元にして新しいプロファイルが
%SystemRoot%\Profiles\%USERNAME%
に作られる。
認証サーバー(ログオンサーバー)上の NETLOGON 共有内にポリシー
ファイル(NTConfig.POL
)がある場合、その内容は
NTUser.DAT
に適用され、最終的にはレジストリの
HKEY_CURRENT_USER
部分に適用される。
ユーザーがログアウトする際、そのプロファイルが移動プロファイルで
あれば、指定されたプロファイルの場所に書き出される。その後
HKEY_CURRENT_USER
の内容から
NTuser.DAT
ファイルが再度作成される。つまり、
次回のログイン時には NETLOGON 共有内に
NTConfig.POL
が存在するべきではなく、そのひとつ
前のNTConfig.POL
がプロファイル内にあれば、
それが有効になる。この効果はタトゥーイング(入れ墨)と呼ばれる。
Windows NT4 のプロファイルのタイプはローカルか
移動のどちらかである。ローカルプロファイルは
%SystemRoot%\Profiles\%USERNAME%
に置かれる。
以下のレジストリキーを作っておかない限り、移動プロファイルも同様に
残ったままとなる。
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\ winlogon\"DeleteRoamingCache"=dword:0000000
このケースでは、
(%SystemRoot%\Profiles\%USERNAME%
にある)
ローカルのコピーは、ログアウト時に削除される。
Windows NT4 では後述のレジストリキーを変更することで、
マイドキュメント
といった共有リソースのデフォルト
位置をネットワーク共有上にリダイレクトすることができる。これらの変更は
システムポリシーエディターを使って行える。これを GUI 上で行いたい
場合は、ポリシーエディターで自分自身のテンプレート拡張を作る必要がある
かもしれない。別の方法としては、まずデフォルトのユーザープロファイル
を作成し、そのユーザーでログインしてからregedt32
でキー設定の編集を行う。
あるフォルダーをデフォルトのユーザープロファイルとしたい場合のレジストリ ハイブキーは、Windows NT4 の場合以下で制御できる:
HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Explorer \User Shell Folders
前述のハイブキーには自動的に管理されるフォルダーがある。デフォルトの エントリはthe next tableにある。
Table 27.1. User Shell Folder レジストリキーのデフォルト値
名前 | デフォルト値 |
---|---|
AppData | %USERPROFILE%\Application Data |
Desktop | %USERPROFILE%\Desktop |
Favorites | %USERPROFILE%\Favorites |
NetHood | %USERPROFILE%\NetHood |
PrintHood | %USERPROFILE%\PrintHood |
Programs | %USERPROFILE%\Start Menu\Programs |
Recent | %USERPROFILE%\Recent |
SendTo | %USERPROFILE%\SendTo |
Start Menu | %USERPROFILE%\Start Menu |
Startup | %USERPROFILE%\Start Menu\Programs\Startup |
デフォルトプロファイルの場所の設定を含むレジストリキー:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ User Shell Folders
デフォルトのエントリは デフォルトのプロファイル設定用のレジストリキー にある。
Table 27.2. デフォルトのプロファイル設定用のレジストリキー
Common Desktop | %SystemRoot%\Profiles\All Users\Desktop |
Common Programs | %SystemRoot%\Profiles\All Users\Programs |
Common Start Menu | %SystemRoot%\Profiles\All Users\Start Menu |
Common Startup | %SystemRoot%\Profiles\All Users\Start Menu\Programs\Startup |
Windows XP Home Edition ではユーザーごとのデフォルトプロファイルは 使われず、ドメインセキュリティにも参加できず、NT/ADS スタイルの ドメインにもログインできないので、プロファイル情報は自分自身で持って おくしかない。デフォルトプロファイルを設定できるといろいろと便利なので、 ドメインログオン処理に参加できるような上位レベルの Windows クライアント では、管理者がグローバルのデフォルトプロファイルを事前に作っておき、 グループポリシーオブジェクト(GPO)を経由してそれらを強制的に適用する という仕組みを備えている。
新しいユーザーが最初に Windows 200x/XP マシンにログインすると、
デフォルトプロファイルは
C:\Documents and Settings\Default User
から読みこまれる。システム管理者が必要に応じてこの中身を変更していても、
Windows 200x/XP は喜んでその指示に従う。これは最善の処置とは
とても言えるものではない。なぜなら、このデフォルトプロファイルを
すべての Windows 200x/XP クライアントマシンにコピーして回らなければ
ならないからである。
Windows 200x/XP がドメインレベルのセキュリティに参加する際、
デフォルトのユーザープロファイルが見つからなければ、クライアントは
デフォルトプロファイルを探すために認証サーバーの NETLOGON 共有を
見に行く。ここで Windows の元々の動きとしては、まず
%LOGONSERVER%\NETLOGON\Default User
を見に行き、もしこのディレクトリがあればこの配下のファイルが
クライアント側のC:\Documents and Settings\
直下にある現在 Windows にログイン中のユーザー名にコピーされる。
一方 Samba 側の動きとしては、このパスは smb.conf
の
[NETLOGON]
共有に読み替えられる。
このディレクトリはこの共有の直下にDefault User
という名前で作っておかなければならない。
この場所にデフォルトプロファイルが存在しない場合、Windows 200x/XP はローカルのデフォルトプロファイルを使用する。
ログアウトの際、ユーザーのデスクトッププロファイルはそのユーザーに
関連するレジストリ設定で指定された場所に格納される。(Samba では
自動的に行われるが)ログイン処理の際に特定のポリシーが作られ
もしくは渡されない場合、ユーザーのプロファイルはローカルマシンの
C:\Documents and Settings\%USERNAME%
パス配下にのみ書きこまれる。
デフォルトの振る舞いを変更したい場合は、以下の3つの方法を使えばよい:
ローカルマシンのレジストリキーを手作業で変更し、NETLOGON 共有の 直下に新しいデフォルトプロファイルを置く。保守でいっせいに行う 必要があるので、この方法はお勧めしない。
この振る舞いを指定した NT4 スタイルの NTConfig.POL ファイルを 作成し、それを新しいデフォルトプロファイルと共に NETLOGON 共有の直下に置く。
これを Active Directory を通して行うように強制する GPO を 作成し、新しいデフォルトプロファイルを NETLOGON に置く。
Windows 200x/XP において、デフォルトユーザープロファイルの一部 となるフォルダーに関する振る舞いに影響を与えるレジストリのハイブ キーは以下のエントリーである:
HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Explorer\User Shell Folders\
このハイブキーには自動的に管理されるフォルダーのリストが含まれる。 デフォルトのエントリーは 次の表にある。
Table 27.3. デフォルトユーザープロファイルへのパスのデフォルト値 を持つレジストリエントリー
名前 | デフォルト値 |
---|---|
AppData | %USERPROFILE%\Application Data |
Cache | %USERPROFILE%\Local Settings\Temporary Internet Files |
Cookies | %USERPROFILE%\Cookies |
Desktop | %USERPROFILE%\Desktop |
Favorites | %USERPROFILE%\Favorites |
History | %USERPROFILE%\Local Settings\History |
Local AppData | %USERPROFILE%\Local Settings\Application Data |
Local Settings | %USERPROFILE%\Local Settings |
My Pictures | %USERPROFILE%\My Documents\My Pictures |
NetHood | %USERPROFILE%\NetHood |
Personal | %USERPROFILE%\My Documents |
PrintHood | %USERPROFILE%\PrintHood |
Programs | %USERPROFILE%\Start Menu\Programs |
Recent | %USERPROFILE%\Recent |
SendTo | %USERPROFILE%\SendTo |
Start Menu | %USERPROFILE%\Start Menu |
Startup | %USERPROFILE%\Start Menu\Programs\Startup |
Templates | %USERPROFILE%\Templates |
値がセットされていない、“Default”と呼ばれるエントリーもある。
デフォルトのえんとりーの型はREG_SZ
である。
これ以外の全ての型はREG_EXPAND_SZ
である。
全てのフォルダーがネットワークサーバー上の特定の場所に格納されて いる場合、移動プロファイルを処理するスピードには大きな違いが出る。 つまり、ログインやログアウトのたびに Outlook の PST ファイルを ネットワークの向こうに書き出す必要はないということだ。
これをネットワーク上の場所にするには、以下の例に従えばよい:
%LOGONSERVER%\%USERNAME%\Default Folders
これにより、フォルダーはユーザーのホームディレクトリーにある
Default Folders
という名前のディレクトリー
配下に格納される。また以下の書式で指定してもよい:
\\SambaServer
\FolderShare
\%USERNAME%
この場合、デフォルトフォルダーは
SambaServer
という名前のサーバー上にある
FolderShare
という名前の共有の下の、
Linux/UNIX ファイルシステムによって Windows ユーザーの名前を
つけられたディレクトリーに格納される。
いったんデフォルトプロファイルの共有を作ったら、その中に移行する ユーザーのプロファイルを(デフォルト値であれカスタマイズしたもの であれ)を置かなければならないことに注意して 欲しい。
Windows 200x/XP のプロファイルはローカル または移動のいずれかである。移動プロファイルは 以下のレジストリキーが作られていない限りローカルにキャッシュされる:
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\ Windows NT\CurrentVersion\winlogon\"DeleteRoamingCache"= dword:00000001
この設定をすると、ログアウト時にローカルのキャッシュは削除される ようになる。
Samba のメーリングリストで質問があった典型的なエラーや問題、 質問内容を以下に示す。
Samba-2.2.x では、移動プロファイルをサポートするか否かという 選択肢しかない。これはグローバル設定である。デフォルトでは 移動プロファイルを持つことになっており、デフォルトのパスは ユーザーのホームディレクトリー配下にある。
グローバルで無効にすると、誰も移動プロファイルを持てなくなる。 移動プロファイル自身は有効にするが、これを特定のマシンにしか 適用させたくない場合は、移動プロファイルサポートをしたくない 個々のマシンにおいて、これを無効にする設定をレジストリに書き 込んでやらなければならない。
Samba-3 では、グローバル設定を smb.conf
に書いておき、
各ユーザーごとの設定を(Windows NT4/200x の)ドメインユーザー
マネージャで上書きすることができる。
どのケースにおいても、各ユーザーごとにひとつのプロファイルしか 持てない。このプロファイルは以下のいずれかになる:
そのユーザー固有のプロファイル
必須プロファイル(ユーザーは変更できない)
グループプロファイル (実際は必須となる すなわち変更不可)
あるユーザーからの要求: “ 移動プロファイルを実装して欲しくない。 各ユーザーにローカルプロファイルだけを与えたい。 私はこのエラーでひどく損害を受けた。 この2日間、あらゆることを試してみた。 Google を検索したりもしてみたが、役に立つ情報はなかった。 助けてください。 ”
選択肢としては、以下のようになるだろう:
ログアウト時に「ローカルの」プロファイルを 自動で消すようなレジストリキーがないことがわかっている。
ユーザーがネットワークにログオンすると、中央に格納された プロファイルがワークステーションにコピーされてローカルの プロファイルが作られる。このローカルプロファイルは、 レジストリキーが変更されてログアウト時の自動削除が有効に ならない限りは永続的になる(ワークステーションのディスク 上に残る)。
移動プロファイルの選択をする場合:
一般的には中央の(もしくは便宜上ローカルにある) サーバー上のプロファイル用共有に格納されている。
ワークステーションはプロファイルのローカルコピーを キャッシュ(格納)する。このキャッシュされたコピーは、 次回のログイン時にプロファイルがダウンロードできなかった 場合に使用される。
これらは中央のプロファイルサーバーから読み込まれる。
必須プロファイルはユーザー用としてだけではなく、 そのユーザーが属するすべてのグループのためにも作られる。 必須プロファイルを通常のユーザーが変更することはできない。 これを変更したり再構成したりできるのは、システム管理者に限られる。
Windows NT4/200x/XP のプロファイルは、そのサイズが最低 130KB から 巨大なサイズまで変動する。プロファイルの中の多くを占めるのは、往々 にして Outlook の PST ファイルであり、これはギガバイトレベルまで 膨らむこともある。(好ましい状態で運用されている環境における) 平均的な移動プロファイルのサイズは、計画段階では 2MB 程度であると 考えればよいだろう。きちんと管理されていない環境では、プロファイルが 2GB まで膨れ上がったのを見たことがある。こうなるとログオンに1時間 くらいもかかってユーザーからの不満が出るかもしれないが、おおかた くだらないごみファイルをため込んでいるのであろう。
この議論のポイントは、移動プロファイルを使って変更できる設定とできない 設定をうまくコントロールしてやれば、問題の少ないサイト運用ができる ということである。
PST 問題に対するマイクロソフトの回答は、すべての電子メールを MS Exchange Server バックエンドに格納するべき、というものである。 これを使えば PST ファイルが必要なくなる。
ローカルプロファイルの意味するところは:
それぞれのマシンが多くのユーザーによって使用されるなら、ローカル プロファイルを格納するために多くのディスク領域が必要になる。
ユーザーがログインするそれぞれのワークステーションにはそれぞれの プロファイルが格納されている。これらはマシン間で全く別物に なっているかもしれない。
一方、移動プロファイルの意味するところは:
ネットワーク管理者は、全ユーザーのデスクトップ 環境をコントロールできる。
移動プロファイルを使うと、ネットワーク管理の オーバーヘッドを劇的に削減できる。
長時間のスパンで考えれば、ユーザーが問題に直面する 危険性が減るだろう。
“ クライアントがドメインコントローラーにログオンする際、クライアントは ダウンロードするべきプロファイルを検索する。我々はデフォルト プロファイルをどこに置くべきだろうか? ”
まず Samba サーバーはドメインコントローラーとして構成する必要がある。
そのためには smb.conf
に以下の設定を行う:
security = user |
os level = 32 (or more) |
domain logons = Yes |
次に [netlogon]
が必須で、ここは全ユーザーが
読めるようになっていなければならない。ここに既存のプリンターやドライブ
の割り当てをするためのログオンスクリプトを追加しておくのもよいだろう。
ワークステーションの時刻をログオンサーバーと自動的に同期させる
仕組みもある(これもやっておくことが好ましい)。
ローカルワークステーションのキャッシュ(=ディスク領域)から移動
プロファイルを自動検出させるには、
グループポリシーエディターを使って
NTConfig.POL
と呼ばれるファイルを作成し、
この中で適切な設定を行っておく。このファイルは
netlogon
共有の直下に置いておかなければ
ならない。
Windows クライアントはドメインのメンバーである必要がある。 ワークグループのマシンではネットワークログオンが使えないので ドメインプロファイルによる運用はできない。
移動プロファイル用に smb.conf
に追加する項目:
logon path = \\%N\profiles\%U |
# Default logon drive is Z: |
logon drive = H: |
# This requires a PROFILES share that is world writable. |
Table of Contents
この章は、何らかの PAM が利用できる UNIX/Linux システムに対して Winbind ベースの認証を導入する際の助けになるだろう。Winbind を使うと、いずれかの Windows NT ドメイン、Windows 200x の Active Directory ベースのドメイン、 そして Samba ベースのドメイン環境において、ユーザーレベルのアプリケーション アクセス認証を利用できるようになる。また、あなたの Samba 環境の設定に 対する適切な PAM ベースのローカルホストアクセス制御にも役立つ。
PAM 経由の Winbind の設定方法を知ることに加え、さらに一般的な PAM 管理
の可能性と、特に pam_smbpass.so
のようなツールを
導入して便利に使う方法も学ぶことができるだろう。
Winbind を使うのは、PAM 構成を単独で行うよりも敷居が高い。Winbind に関する より詳細な情報については Winbind: ドメインアカウントを使う を参照されたい。
現在、多くの UNIX システム(例:Oracle(Sun)Solaris)や xxxxBSDファミリーおよび
Linux では、着脱可能な認証モジュール(PAM)機能を使って全ての認証、承認処理、
リソースの制御サービスを提供している。PAM の導入以前は、システムパスワード
データベース(/etc/passwd
)以外のものを使おうとするなら、
セキュリティサービスを提供するすべてのプログラムそれぞれに対して代替手段
を準備する必要がある。つまり、login
,
passwd
, chown
といったものの代替手段
を別途用意しなければならないということである。
PAM を使うと、これらのセキュリティプログラムを、これらが依存する認証/
承認インフラから切り離すことができる。PAM を構成するには、
/etc/pam.conf
という1つのファイルを適切に変更する
(Solaris)か、または/etc/pam.d
配下にある個別の制御
ファイルを編集する。
PAM が有効になっている UNIX/Linux システムでは、動的なロードができる適切な ライブラリモジュールが利用できるようになっていれば、システムでさまざまな 認証バックエンドを使うように構成するのは簡単である。それらのバックエンドは システムでローカルに閉じていてもよいし、リモートサーバー上で集約されていてもよい。
PAM サポートモジュールで使えるもの:
/etc/passwd
これらの PAM モジュールは標準の UNIX ユーザーデータベースを利用する。
最も有名なものは、pam_unix.so
,
pam_unix2.so
, pam_pwdb.so
,
pam_userdb.so
と呼ばれるものである。
pam_krb5.so
モジュールを使うと、ケルベロス準拠の
あらゆるサーバーを使える。このツールは MIT Kerberos, Heimdal Kerberos,
そしておそらく(もし有効であれば)Microsoft Active Directory にアクセス
するのにも使える。
pam_ldap.so
モジュールを使うと、LDAP v2 もしくは v3
準拠のあらゆるバックエンドサーバーを使える。よく使われる LDAP バックエンド
サーバーには OpenLDAP v2.0 and v2.1, Sun ONE iDentity server,
Novell eDirectory server, Microsoft Active Directory がある。
pam_ncp_auth.so
モジュールを使うと、バインダリ(Bindery)が
有効な NetWare コアプロトコルベースのサーバーによる認証を利用できるようになる。
pam_smbpass.so
と呼ばれるモジュールを使うと、Samba の
smb.conf
ファイルで設定された passdb バックエンドのユーザー認証を利用
できるようになる。
pam_smb_auth.so
モジュールは、オリジナルの MS Windows
ネットワーク認証のためのツールである。Winbind モジュールがリリース
されている現在、このモジュールはすでに多少古臭くなってしまっている。
pam_winbind.so
モジュールは、Samba は MS Windows の
ドメインコントローラーからの認証情報を取得できるようにするものである。
これにより、PAM が有効なアプリケーションに対して認証されたユーザーへの
アクセス権を与えるのが簡単になる。
PAM RADIUS (Remote Access Dial-In User Service) と呼ばれる認証モジュールがある。 ほとんどのケースでは、管理者がこのツールのソースコードを持ってきて自分自身で インストールを行う必要がある。RADIUS プロトコルは多くのルータやターミナル サーバーで使われているプロトコルである。
上記のうち、pam_smbpasswd.so
と pam_winbind.so
モジュールは、Samba 自身が提供するものである。
いったんこれらのモジュールを設定してしまえば、広範囲にまたがるネットワーク 帯域や PAM を利用した効率的な認証サービスを提供するような分散 Samba ドメイン コントローラーの利用においても、高い柔軟性を得ることができる。つまり、単一の ユーザーアカウントデータベースを使って、中央集中的な管理や保守の行き届いた 分散認証を実現できるのである。
システム管理者が自分のシステム上のアプリケーションにアクセス権を付与する際、
PAM はかなり柔軟に設定できるように設計されている。PAM によって制御される
システムセキュリティのためのローカル設定には、単一ファイル
/etc/pam.conf
と /etc/pam.d/
ディレクトリーの2つがある。
この章では、これらのファイルで記述するエントリに関する正しい文法、および 一般的なオプションについて解説する。設定ファイルにおける PAM 特有の トークンでは、大文字小文字の区別を行わない。ただし、モジュールのパス については大文字小文字を区別する。なぜなら、これらはファイルの名前を 示すものであり、大文字小文字を区別するような一般的なファイルシステム の性質に影響を受けるからである。与えられたモジュールに渡すための 引数が大文字小文字を区別するかどうかは、それぞれのモジュールで規定 されている。
後述の設定行に加え、システム管理者の便宜のために2つの特殊文字がある: “#” から行末まではコメントとみなされる。またモジュールを 指定する行については “\” で改行をエスケープすることで、 次の行にまたがることができる。
PAM の認証モジュール(ダイナミックリンクされたライブラリファイル)が
既定値の位置にある場合は、そのパスを明示する必要はない。Linux の場合、
既定値の位置は /lib/security
となる。モジュールが
既定値位置以外にある場合は
auth required /other_path/pam_strange_module.so
のようにパスを明示しなければならない。
このセクションの残りの部分は、Linux-PAM プロジェクトのドキュメントから の引用である。PAM に関する詳細は the Official Linux-PAM home page を参照のこと。
/etc/pam.conf
ファイル中の一般的な設定行は、
以下の書式で記述する:
サービス名 モジュールタイプ 制御フラグ モジュールパス 引数
これら各トークンの意味について解説する。Linux-PAM を構成するための2番目
のやり方(最近はむしろこちらの方が多いようだが)は、
/etc/pam.d/
ディレクトリーの中身を介するという方法
である。それぞれのトークンの意味するところを解説した後、この方法について
述べることにする。
このエントリに関連付けられるサービスの名前。ftpd
,
rlogind
, su
のように、サービス名は
アプリケーションにつけられた伝統的な名前であることが多い。
既定値の認証メカニズムを定義するために予約されている、特別な名前もある。
これは OTHER
と呼ばれるが、大文字小文字は固定されて
いない。名前付きサービスに特化したモジュールがある場合、
OTHER
エントリーは無視される事に注意。
(現時点では)以下の通り4つのタイプのモジュールがある。
auth:
このモジュールタイプは、ユーザーを認証
するにあたって2つの側面がある。まず、アプリケーションに対して
パスワード問い合わせの指示を行うか、または別の手段を使って、操作
しているユーザーが誰なのかを特定する。次に、このモジュールはその
資格認定から承認という性質を通して(/etc/groups
ファイルとは独立した形で)グループの会員資格やその他の特権に関する
許可を与えることができる。
account:
このモジュールは、認証をベースとしない
アカウント管理を行う。よくある利用法としては、利用時間帯、現時点で利用
可能なシステムリソース(最大ユーザー数)、またはユーザーがログインした場所
などをベースとした、サービスへのアクセスの制限や許可が挙げられる。
たとえば “root” ログインの許可は、コンソールからのみに制限
されているかもしれない。
session:
このモジュールは、主に対象のユーザーが
サービスを割り当てられる前後に行われるべきことに関連付けられる。
たとえばそのユーザーに関する何らかのデータ交換をする際のオープン/クローズ
情報のログを取ったり、ディレクトリをマウントすることなどが挙げられる。
password:
この最後のモジュールタイプは、そのユーザーに
関連する認証トークンを更新するために必要なものである。典型的には、
“チャレンジ/レスポンス” 認証を行う
(auth)
モジュールタイプがある。
制御フラグは、関連するモジュールの成功/失敗に対して PAM
ライブラリがどう対応するのかを指示するのに使われる。PAM モジュール群は
スタック化(同じタイプのモジュール群を次々に重ねること)できるので、
制御フラグがそれぞれのモジュールの相対的な重要度を決定する。
アプリケーションは /etc/pam.conf
ファイルにある
モジュールについて、個々の成功や失敗に影響されない。その代わり、
Linux-PAM ライブラリからの成功や失敗の応答のサマリを受け取る。
これらのモジュールは、/etc/pam.conf
に記述
されている順に実行される。つまり前の方にあるエントリは後ろの方の
ものより先に実行される。Linux-PAM v0.60 の場合、制御フラグは2つの
文法のうちのいずれかで定義できる。
制御フラグについてのシンプルな(かつ従来の)文法では、特定のモジュール
の成功や失敗について、それらを通知するための重大度を単一のキーワードで
指定する。キーワードには required
,
requisite
, sufficient
,
optional
の4種類ある。
Linux-PAM ライブラリでは以下の方式でこれらのキーワードを 解釈する。
required:
このモジュールタイプ機能が成功するためには
このモジュールが成功することが必須である。ただしこのモジュールが失敗
した場合でも、(同じモジュールタイプを持つ)残りのすべてのモジュールの
実行が完了するまでは、失敗したことはユーザーには通知されない。
requisite:
required と似ているが、このモジュール
が失敗を返したとき制御が直接アプリケーションに戻されるところが異なる。
その戻り値は、失敗したモジュールのうち最初に required もしくは requisite
指定されていたものに関連付けられる。安全でない媒体を通してユーザーが
パスワードを入力するような可能性がある場合、このフラグはその状況を排除
するために使える。そのような可能性が残っていると、システム上の有効な
アカウントの情報を攻撃者に知らせてしまうようなことにつながりかねない。
このような可能性があると、共用ホスト環境で慎重に扱うべきパスワードを
公開してしまうようなゆゆしき環境において、一方的に不利になるだろう。
sufficient:
このモジュールが成功すると、Linux-PAM
ライブラリがこのモジュールタイプについてその目的を達成したものとするのに
sufficient
(十分である)とみなされる。
これまでに要求されたモジュールのうち失敗したものがない場合、このタイプに
関して“スタックされた”モジュールは、これ以上起動されない
(この場合、この後に続くモジュールは起動されない)。
ただし、このモジュールが失敗しても、このモジュールタイプレベルで成功した
アプリケーションについては致命的エラーとはみなされない。
optional:
この制御フラグは、その名前が示して
いるように、そのモジュールの成功/失敗が、そのユーザーアプリケーション
がサービスを提供できるかどうかを決めるものではないことを示す。一般に、
そのモジュールスタック全体が成功か失敗かを決定する際、Linux-PAM
はこのようなモジュールを考慮しない。しかしながら、それ以前もしくは
それ以降のどのモジュールも明確に成功か失敗かを示さない場合、この
モジュールがアプリケーションへの応答の性質を決めることがある。
後者のひとつの例として、他のモジュールが PAM_IGNORE のようなものを
返した場合が挙げられる。
ユーザーを認証する方法について、その文法が複雑に(新しく)なれば
なるほど、管理者はより詳しく記述し、より細かく制御できるように
なるものである。この制御フラグの書式は、以下のように
値=アクション
トークンの並びが
大括弧で区切られたものである:
[値1=アクション1 値2=アクション2 ...]
ここで、値1
は以下の戻り値のいずれかである:
success; open_err; symbol_err; service_err; system_err; buf_err;
perm_denied; auth_err; cred_insufficient; authinfo_unavail;
user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err;
cred_unavail; cred_expired; cred_err; no_module_data; conv_err;
authtok_err; authtok_recover_err; authtok_lock_busy;
authtok_disable_aging; try_again; ignore; abort; authtok_expired;
module_unknown; bad_item;
とdefault
.
最後のdefault
は、明示的に定義されない戻り値に対する
動作を規定するのに使える。
アクション1
には正の整数かまたは以下のトークン
のいずれかを指定する:
ignore
; ok
; done
;
bad
; die
; reset
.
正の整数 J がアクションとして指定された場合、現在のモジュールタイプについて
続く J 個のモジュールをスキップする。この方法により、管理者は異なった実行
パスを持つ多くのスタックされたモジュールを、適度に洗練された方法で組み合わせる
ことができる。個々のモジュールの反応によって、どのパスにあるものが適用されるかが
決定される。
ignore:
モジュールスタックに対して使われると、その
モジュールの戻り値は、アプリケーションが受け取るリターンコードには影響しない。
bad:
このアクションが指定されると、戻り値はモジュールの
失敗を表しているとみなされる。このモジュールがスタックの中で最初に失敗すると、
その戻り値はスタック全体の値として使われる。
die:
bad と同じだが、さらにモジュールスタックが終了
して即時に PAM がアプリケーションに結果を返す。
ok:
この戻り値をモジュールスタック全体の戻り値
として直接返すべきだと管理者が考えていることを PAM に教える。つまり、
このスタックの直前の状態が戻り値 PAM_SUCCESS を返すことになっていた
場合は、モジュールの戻り値がこの値を上書きする。もしスタックの直前の
状態が特定のモジュールの失敗を表す何らかの値を保持している場合は、
この ok
値はその値を上書きしない。
done:
ok
と同じだが、
モジュールスタックを終了させて PAM の制御を即時にアプリケーションに
戻すという副作用があるところが異なる。
reset:
モジュールスタックの状態を保持するメモリ
をクリアし、次のスタックモジュールから実行を再開する。
required
; requisite
;
sufficient
; optional
はそれぞれ [...] という構文をもつという意味では同等の、以下の表現を
備えている:
required
は
[success=ok new_authtok_reqd=ok ignore=ignore default=bad]
と同等。
requisite
は
[success=ok new_authtok_reqd=ok ignore=ignore default=die]
と同等。
sufficient
は
[success=done new_authtok_reqd=done default=ignore]
と同等。
optional
は
[success=ok new_authtok_reqd=ok default=ignore]
と同等である。
この新しい書式が持つパワーの感触をつかむために、これで何ができる
のかを体験してみるとよいだろう。Linux-PAM-0.63 ではクライアント・
プラグイン・エージェントの概念が導入された。これにより、PAM では
クライアント・サーバー・アプリケーションに対して、トランスポート・
プロトコルの継承を利用したマシン間の認証を可能にしている。
[ ... value=action ... ]
という制御用構文
により、アプリケーションがそれに準拠するクライアントに対して
バイナリ・プロンプトのサポートを構成できるようになっている。ただし
レガシーアプリケーションの場合は柔軟に代替認証モードにフェイル
オーバーできる。
動的ローダブルオブジェクトファイルのパス名 - 差し替え可能な
モジュールそのもの。モジュールパスの最初の文字が
“/” の場合、それは絶対パスであるとみなされる。
そうでない場合、与えられたモジュールパスは既定値のモジュール
パスである /lib/security
の後ろに付加される
(ただし前述の注意事項を参照のこと)。
引数は、起動時にモジュールに渡されるトークンのリストであり、典型的な Linux のシェルコマンドへの引数と同様である。一般的に、有効な引数は オプションであり、与えられたモジュール固有のものであることが多い。 無効な引数はモジュールによって無視される。しかしながら、無効な引数に 出会った場合、そのモジュールは syslog(3) に対してエラーメッセージを 出力しなければならない。共通的なオプションについては次の節を 参照して欲しい。
引数の中に空白を含める場合は引数全体を大括弧 [] で括るようにする。 次に例を示す:
squid auth required pam_mysql.so user=passwd_query passwd=mada \ db=eminence [query=select user_name from internet_service where \ user_name=“%u” and password=PASSWORD(“%p”) and service=“web_proxy”]
この書式を使う場合は文字列の中に “[” 文字を含んでもよい。 また文字列の中に “]” 文字を含める場合は、引数の解析が 正しく行えるように “\[” を使うべきである。すなわち以下の ようになる。
[..[..\]..] --> ..[..]..
設定ファイルの中でひとつでも書式が正しくない行があれば、(エラーが 起こって)認証処理は失敗すると思った方がよい。対応するエラーは syslog(3) への呼び出しを通してシステムのログファイルに書き込まれる。
以下は設定ファイル /etc/pam.d/login
の例である。
この例ではすべてのオプションがコメント状態をはずされて(=有効になって)おり、
おそらくこのままでは使い物にならないだろう。というのは、ログインプロセス
が成功するまでに多くの条件が積み重なっているからである。
pam_pwdb.so
の呼び出しを除き、原則的にはすべての
条件をコメントアウトして無効にすることができる。
#%PAM-1.0
# The PAM configuration file for the “login” service
#
auth required pam_securetty.so
auth required pam_nologin.so
# auth required pam_dialup.so
# auth optional pam_mail.so
auth required pam_pwdb.so shadow md5
# account requisite pam_time.so
account required pam_pwdb.so
session required pam_pwdb.so
# session optional pam_lastlog.so
# password required pam_cracklib.so retry=3
password required pam_pwdb.so shadow md5
PAM では交換式モジュールが利用できる。サンプルシステムでは 以下のものが利用可能:
$
/bin/ls /lib/security
pam_access.so pam_ftp.so pam_limits.so pam_ncp_auth.so pam_rhosts_auth.so pam_stress.so pam_cracklib.so pam_group.so pam_listfile.so pam_nologin.so pam_rootok.so pam_tally.so pam_deny.so pam_issue.so pam_mail.so pam_permit.so pam_securetty.so pam_time.so pam_dialup.so pam_lastlog.so pam_mkhomedir.so pam_pwdb.so pam_shells.so pam_unix.so pam_env.so pam_ldap.so pam_motd.so pam_radius.so pam_smbpass.so pam_unix_acct.so pam_wheel.so pam_unix_auth.so pam_unix_passwd.so pam_userdb.so pam_warn.so pam_unix_session.so
以下のログインプログラムの例では、システムパスワードデータベース
(/etc/passwd
,
/etc/shadow
, /etc/group
)
を使う pam_pwdb.so
を
pam_smbpass.so
で置き換えている。
後者では Microsoft MD4 暗号化パスワードハッシュを含む Samba
のデータベースを使う。このデータベースは使用している UNIX/Linux
システムの実装により
/usr/local/samba/private/smbpasswd
,
/etc/samba/smbpasswd
,
/etc/samba.d/smbpasswd
のいずれかに格納される。pam_smbpass.so
モジュールは Samba 2.2.1 以降で提供される。このモジュールを
コンパイルしたい場合は、Samba の configure
スクリプト実行時に --with-pam_smbpass
オプションを指定する。pam_smbpass
モジュールに関する詳細については Samba ソースの配布物の
source/pam_smbpass
ディレクトリにある
ドキュメントを参照して欲しい。
#%PAM-1.0
# The PAM configuration file for the “login” service
#
auth required pam_smbpass.so nodelay
account required pam_smbpass.so nodelay
session required pam_smbpass.so nodelay
password required pam_smbpass.so nodelay
以下に、ある Linux システムにおける PAM の設定ファイルを示す。
既定値の設定では pam_pwdb.so
を使う。
#%PAM-1.0
# The PAM configuration file for the “samba” service
#
auth required pam_pwdb.so nullok nodelay shadow audit
account required pam_pwdb.so audit nodelay
session required pam_pwdb.so nodelay
password required pam_pwdb.so shadow md5
以下の例では、基本的な Samba 認証であっても
smbpasswd
データベースを使うようになっている。
このような設定を行った場合、passwd
プログラムに
対しても影響を及ぼす。つまり、smbpasswd
の
パスワードを passwd
コマンドで変更できるようになる:
#%PAM-1.0
# The PAM configuration file for the “samba” service
#
auth required pam_smbpass.so nodelay
account required pam_pwdb.so audit nodelay
session required pam_pwdb.so nodelay
password required pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
PAM では階層的な(スタックされた)認証の仕組みを提供している。
たとえば、ある PAM モジュールが受け取った情報を、PAM スタックの
次のモジュールに渡すことができる。PAM に関する特定の機能の詳細については、
お使いのシステムに特化したドキュメントを参照して欲しい。
さらにいくつかの Lunux の実装では、すべての認証を中心となる単一のファイルで
設定できる pam_stack.so
と呼ばれるモジュールが
提供されている。
pam_stack.so
方式は管理者の手間を軽減
してくれるので、熱心なファンもいる。
もっとも、環境によってもいろんな問題があるわけであり、前述のどの方式を
取るにしてもそれぞれのトレードオフがある。より有益な情報を探すために、
PAM のドキュメントをあたってみるのもよいだろう。
obey pam restrictions と呼ばれる smb.conf
のオプションがある。このオプションに関する SWAT のヘルプを以下に示す:
Samba が PAM サポート (
--with-pam
) 付きでコンパイル されている場合、Samba が PAM の account および session 管理 ディレクティブに従うかどうかをこのパラメーターで 制御できる。 PAM を使うが認証は平文のみで、かつどの account/session 管理も 無視するというのが既定値の動作である。 encrypt passwords = yes の場合、Samba は常に認証については PAM を無視する。その理由は、 SMB パスワード暗号を使う場合に必要なチャレンジ/レスポンス方式の 認証メカニズムを PAM モジュールが サポートしていないからである。
どんな OS であっても、その OS 自身がアクセス可能なユーザー証明情報が
(どこからか)提供されていることを前提としている。UNIX ではユーザー
識別子(UID)だけでなくグループ識別子(GID)も必要となる。これらはいずれも
単純な整数値であり、/etc/passwd
といったパスワード
バックエンドより取得する。
Windows NT サーバーでは、ユーザーとグループは相対ID(RID)に割り当て られている。これらはユーザーやグループが作られる際、ドメイン毎に 一意となる。Windows NT のユーザーやグループを UNIX のユーザーやグループ に変換するためには、RID と UNIX のユーザー/グループの ID を マッピングする必要がある。これが winbind が行う仕事のひとつである。
winbind のユーザーとグループはサーバーから解決要求が出され、ユーザーと グループの ID が指定された範囲内で割り当てられる。クライアントが ユーザーとグループを列挙するコマンドを実行すると、すぐに既存の全 ユーザーとグループがマッピングされ、割り当て処理が先着順に行われる。 割り当てられた UNIX ID は Samba の lock ディレクトリ配下のデータベース ファイルに保持されて記憶される。
これにより、目先が利く管理者なら、pam_smbpass.so
や
winbindd
と、ldap
のような
分散型の passdb backend との
組み合わせにより、(Linux のような)PAM を意識したプログラムや
アプリケーションからも使うことのできる、中央集権型で管理された分散型の
ユーザー/パスワードデータベースが使えるようになるということが理解
できるだろう。このお膳立てにより、広範囲のネットワーク認証のトラフィック
が削減できるという限りにおいては、マイクロソフトのActive Directory Service
(ADS)に比較して、特に強力な優位性を持てる。
UNIX の ID データベースに対応する RID はユーザーとグループのマッピング
が格納されているファイルにのみ存在し、winbindd
によって格納される。このファイルが削除されていたり壊れていたりする場合、
winbindd
はどのユーザーやグループが Windows NT
のユーザーやグループの RID と対応するのかを決定できなくなる。
pam_smbpass
は PAM モジュールのひとつであり、
システム上で smbpasswd
(Sambaのパスワード)
データベースと UNIX のパスワードファイルとの同期を取るために
使われる。PAM は Solaris, HPUX, Linux などの UNIX オペレーティングシステム
上でサポートされている API であり、認証メカニズムに対する標準的な
インターフェースを提供する。
このモジュールはローカルにある smbpasswd
ユーザー
データベースを使って認証する。リモートの SMB サーバーで認証したり、
システム上の SUID root されたバイナリの存在を調べたいという向きには、
pam_winbind
の方を使うことをお勧めする。
このモジュールで認識されるオプションについては、 次のテーブルを参照して欲しい。
Table 28.1. pam_smbpass
で認識されるオプション
debug | より多くのデバッグ情報を出力する |
audit | debugと似ているが、認識できないユーザー名も表示する |
use_first_pass | ユーザーにパスワード入力を求めない。 パスワードは PAM_ 項目から持ってくる |
try_first_pass | 直前の PAM モジュールからパスワードの取得を試みる。 取得できなければユーザーからの入力を求める。 |
use_authtok | try_first_pass に似ているが、 (パスワードモジュールだけをスタックさせるための) 新しい PAM_AUTHTOK が事前にセットされていなければ『失敗する』 |
not_set_pass | このモジュールで使われたパスワードを他のモジュールに流用させない |
nodelay | 認証の失敗までに最大1秒の遅延を挟まない |
nullok | パスワードなしを認める |
nonull | パスワードなしを認めない。これは Samba の設定に優先する。 |
migrate | “auth” コンテキストでのみ意味を持つ。 成功した認証で使われたパスワードを使って smbpasswd ファイルを更新する。 |
smbconf=ファイル名 | smb.conf ファイルへの別のパスを指定する |
Linux の /etc/pam.d/
形式のファイル構造で
pam_smbpass.so
を使うときの例を以下に示す。
このツールを別のプラットフォームに実装したいと思っている方は、
適当に読み替えてみてほしい。
以下の PAM 設定例では、/etc/passwd (/etc/shadow)
が変更されたときに、pam_smbpass を利用して
private/smbpasswd
が連動して変更されるようにしている。
これはパスワードの有効期限が切れたときに(ssh
のような)
アプリケーションがパスワードを変更するような場合に便利である。
#%PAM-1.0 # password-sync # auth requisite pam_nologin.so auth required pam_unix.so account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so nullok use_authtok try_first_pass session required pam_unix.so
以下は pam_smbpass
を使って平文から
Samba 用の暗号化パスワードに移行するための PAM 設定である。
他のメソッドと違い、この方法なら一度も Samba の共有に接続
したことがなくても使える:パスワードを移行すれば、ユーザーが
ftp
で接続したり、ssh
でログインしてメールを取り出したりする場合などにも使える。
#%PAM-1.0 # password-migration # auth requisite pam_nologin.so # pam_smbpass is called IF pam_unix succeeds. auth requisite pam_unix.so auth optional pam_smbpass.so migrate account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password optional pam_smbpass.so nullok use_authtok try_first_pass session required pam_unix.so
以下の例は、従来の smbpasswd
利用時のための
PAM 設定である。private/smbpasswd
全体が
投入され、SMB パスワードが存在しなかったり UNIX のパスワードと
合致しない場合はエラーと見なされる。
#%PAM-1.0 # password-mature # auth requisite pam_nologin.so auth required pam_unix.so account required pam_unix.so password requisite pam_cracklib.so retry=3 password requisite pam_unix.so shadow md5 use_authtok try_first_pass password required pam_smbpass.so use_authtok use_first_pass session required pam_unix.so
以下の PAM 設定例は、pam_krb5
といっしょに
使われる pam_smbpass
を示している。
これは Samba PDC 上で、かつそれがkerberos realmのメンバーで
ある場合に有用である。
#%PAM-1.0 # kdc-pdc # auth requisite pam_nologin.so auth requisite pam_krb5.so auth optional pam_smbpass.so migrate account required pam_krb5.so password requisite pam_cracklib.so retry=3 password optional pam_smbpass.so nullok use_authtok try_first_pass password required pam_krb5.so use_authtok try_first_pass session required pam_krb5.so
PAM は割と扱いづらく、設定エラーを引き起こしやすい。以下に Samba のメーリングリストで見かけたいくつかのケースを紹介する。
あるユーザーからPAM の設定で以下の問題が起こった との報告があった:
auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_unix.so use_first_pass nullok auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_winbind.so password required /lib/security/pam_stack.so service=system-auth
[ctrl][alt][F1]で新しくコンソールを開くと、私の ID “pitie” ではログインできない。ユーザー “scienceu\pitie” でやってみたが、それでもだめだった。
この問題は
pam_stack.so service=system-auth
がある
時に発生する。このファイルに入っている多くの設定には、
すでに実行中ものが二重に入っていることがよくある。
auth
と account
から pam_stack
の行をコメントアウト
したらどうなるかやってみてくれ。それで動くなら、
/etc/pam.d/system-auth
ファイルを見て、
その中で本当に必要な行だけを /etc/pam.d/login
ファイルにコピーすればいい。別のやり方として、もしすべての
サービスで winbind を動かしてもいいなら、
/etc/pam.d/system-auth
に winbind 固有の
設定を追加してもいい。
“
僕の smb.conf
は正しく設定されている。
idmap uid = 12000 と
idmap gid = 3000-3500
を指定しているし winbind
も動いている。
以下のコマンドはちゃんと動いている。
”
root#
wbinfo -u
MIDEARTH\maryo MIDEARTH\jackb MIDEARTH\ameds ... MIDEARTH\rootroot#
wbinfo -g
MIDEARTH\Domain Users MIDEARTH\Domain Admins MIDEARTH\Domain Guests ... MIDEARTH\Accountsroot#
getent passwd
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash ... maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false
“ しかし、このコマンドが失敗する: ”
root#
chown maryo a_file
chown: 'maryo': invalid user
“一体どうなってんの?何か間違ってる?”
名前キャッシュデーモンである nscd
が動いてる
んじゃないかな?そいつを終わらせて、起動しないようにしてくれ。
それでうまくいくと思うよ。
Table of Contents
この章ではNetBIOS over TCP/IPの名前からIPアドレスを解決する事について取り扱う。もしも、 使用しているWindowsクライアントがNetBIOS over TCP/IPを使うように設定されていない場合、 この章は使用している環境には適用されない。もしも使用している設定が、NetBIOS over TCP/IPを 使うのであれば、この章はネットワークの問題を解決するのに手助けとなるだろう。
NetBIOS over TCP/IPはNetBEUIとは関係ない。NetBEUIはNetBIOS over Logical Link Control(LLC) である。最近のネットワークでは、NetBIOSを動かさないことを強く推奨している。また、 NetBEUI over TCP/IPというようなものはない。そのようなプロトコルは、全く完全に 誤解である。
多くのMicrosoft Windows ネットワーク管理者は、UNIX/Linux OS中で実装されているような 基本的なTCP/IPネットワーキングに一度も出会ったことはない。同じく、多くのUNIXとLinux 管理者は、Microsoft Windows TCP/IPベースのネットワークの複雑さ(とそれに対する願望 は無いかもしれない)に出会ったことがない。
この章では、各OS環境において、どのように、名前がIPアドレスに解決されるかについての 基本について、簡単に紹介する。
Microsoft Windows 2000から、Microsoft Windows ネットワークをNetBIOS over TCP/IPなしで 動かすことが可能になった。NetBIOS over TCP/IPは、NetBIOS名前解決にUDPポート137を、 NetBIOSセッションサービスにTCPのポート139を使う。NetBIOS over TCP/IPが、Microsoft Windows 2000とそれ以降のクライアントで無効になると、TCPポート445のみが使われ、 UDPポート137とTCPポート139は使われなくなる。
Windows 2000かそれ以降のクライアントを使うとき、もしも NetBIOS over TCP/IPが無効になって いない場合、クライアントはUDPポート137(NetBIOSネームサービスであり、Windows Internet Name serviceあるいはWINSとしても知られている)とTCPポート445(実際のファイルと印刷データの 転送)を使う。
NetBIOS over TCP/IPが無効の場合、DNSの使用が基本である。現在ほとんどの、 NetBIOS over TCP/IPを無効にした環境では、Microsoft Active Directoryサービス(ADS)を 使っている。ADSは サービスリソースレコード(SRV RR)と増分ゾーン転送(IXFR)を使う、ダイナミックDNSを要求 する。 ADSと同時にDHCPを使うことは、クライアントワークステーションネットワーク設定上で 集中制御管理を行う手段として推奨される。
この節が対象としている重要な設定ファイルは以下の通り:
/etc/hosts
/etc/resolv.conf
/etc/host.conf
/etc/nsswitch.conf
このファイルは静的なIPアドレスと名前の一覧を含んでいる。
127.0.0.1 localhost localhost.localdomain 192.168.1.1 bigbox.quenya.org bigbox alias4box
/etc/hosts
の目的は、名前解決メカニズムを提供することであり、
ユーザーはIPアドレスを覚えなくても済むようになる。
物理的なネットワーク転送レイヤ上で送られたネットワークパケットは、IPアドレスを 使うのではなく、メディアアクセスコントロールアドレス、あるいはMACアドレス を使って通信を行う。IPアドレスは、現在32ビット長で、通常ドット(あるいは ピリオド)で分割された4つの十進数で表現される。 たとえば、168.192.1.1である。
MACアドレスは48ビット(あるいは6バイト)であり、通常2桁の16進数をコロン で分離して表現される。たとえば 40:8e:0a:12:34:56.である。
すべてのネットワークインタフェースはMACアドレスを持たねばならない。MACアドレス に対して1つ以上のIPアドレスを割り当てることができる。IPアドレスとMACアドレスの間に 何らの関係はない。そのようなすべての割り当ては、任意、あるいは自由に行える。 最も基本的なレベルでは、すべてのネットワーク津心は、MACアドレスを使って行われる。 MACアドレスがグローバルに一意で、一般的に、特定のインタフェースに固定されている ので、IPアドレスの割り当てはネットワーク管理の視点から意味をなす。1つ以上のIP アドレスをMACアドレス毎に割り当てられる。1つのアドレスはプライマリIPアドレスで ある必要がある。これは、アドレス解決プロトコル(ARP)の問い合わせで 帰ってくるアドレスである。
ユーザーあるいはプロセスが他のマシンと通信したい場合、プロトコルは、
“マシン名”あるいは“ホスト名”が、TCP/IP設定制御ファイルで
制御される方法で、IPアドレスに解決されるように実装されている。
/etc/hosts
はそのようなファイルの1つである。
送信先のインタフェースのIPアドレスが決まったとき、ARP/RARPと呼ばれるプロトコルが、 対象インタフェースのMACアドレスを識別するのに使われるARPは、すべて1であるMACアドレスを 使って、ローカルネットワークセグメント上のすべてのインタフェースに対してUDPを使って 送信する、ブロードキャストベースの方法である。ネットワークインタフェースは2つのMAC アドレスのみに返信する。そのインタフェース固有のアドレスと、ff:ff:ff:ff:ff:ffという アドレスである。ARP要求からの返信パケットにはMACアドレスと各インタフェースのプライマリ IPアドレスが含まれている。
/etc/hosts
ファイルはすべてのUNIX/Linux TCP/IPインストールの
基本であり、最低でも、localhostとローカルネットワークインタフェースの
IPアドレスとローカルマシン上のプライマリ名を含んでいる。このファイルは、
名前解決方法の出発点となる。つまり、その他の名前解決機構を利用する前に、
基本的な名前解決は行われている。
このファイルで名前解決ライブラリを指定する:
マシンが存在するドメインの名前
完全に一意でないホスト名をIPアドレスに解決しようとする時に 自動的に検索されるべき任意のドメイン名。
名前解決検索を実行するのに問い合わせされる、有効なドメイン ネームサーバーのIP仇レスか名前。
/etc/host.conf
は、/etc/resolv.conf
中で
設定できるようにするための主要な手段である。これはきわめて重要な設定ファイルである。
このファイルは名前解決が処理されるかもしれない順序を制御する。通常の構造は
以下の通り:
order hosts,bind multi on
両方のアドレスが返されるべきである。詳細については、
host.conf
マニュアルページを参照のこと。
このふぁいるは実際の名前解決先を制御する。ファイルは通常以下のようにリゾルバー オブジェクト指定を記述する:
# /etc/nsswitch.conf # # Name Service Switch 設定ファイル # passwd: compat # Alternative entries for password authentication are: # passwd: compat files nis ldap winbind shadow: compat group: compat hosts: files nis dns # Alternative entries for host name resolution are: # hosts: files dns nis nis+ hesiod db compat ldap wins networks: nis files dns ethers: nis files protocols: nis files rpc: nis files services: nis files
もちろん、それらの各メカニズムは、適切な機能かサービスを正しく設定する 事を要求する。
ネットワーク要求/メッセージを送ることが必要にならない限り、TCP/IPネットワークは 何もデータを送らないことに注意すべきである。すべてのTCP/IP通信は、必要時にのみ 通信を行うという原則を仮定している。
バージョン 2.2.0から、Sambaはname service switch機構用の拡張のために、Linuxをサポート
するようになり、Linuxクライアントは、Microsoft Windows NetBIOSの名前解決機能を使える
ようになった。この機能を使うためには、Sambaはmakeコマンドで適切な引数を付けてコンパイル
する必要がある(すなわち、make nsswitch/libnss_wins.so
)。
次に名前解決ライブラリを/lib
ディレクトリにインストールし、
wins
パラメーターを、/etc/nsswitch.conf
ファイル
中の“hosts:”行に追加する必要がある。この時点で、
SambaサーバーとMicrosoft Windowsマシンが存在するワークグループ内にいる、
どこかのMicrosoft Windowsマシンに対してNetBIOSマシン名でping出来る。
Microsoft Windowsネットワークは、各マシンに割り当てられた名前をベースにしている。 これは、“コンピュータ名”,“マシン名”, “ネットワーキング名”,“NetBIOS名”あるいは“SMB名” という、種々の(そして矛盾した)名前で呼ばれている。すべての単語は、ワークグループか ドメイン名の名前にも適用できる“NetBIOS名”を除いて同じものを意味する。 “ワークグループ”と“ドメイン”という単語は、実際、どのマシンが 関連づけられているかという、単なる名前である。すべてのNetBIOS名はきっかり16文字である。 16番目の文字は予約されている。登録されたNetBIOS名のサービスレベル情報を指定する 1バイトとして使われる。そのため、NetBIOSマシン名は、クライアント/サーバーによって 提供される各サービスタイプで登録される。
一意なNetBIOS名と グループ名の表は、典型的なNetBIOS 名前/サービスタイプ登録一覧である。
Table 29.1. 一意なNetBIOS名
MACHINENAME<00> | MACHINENAME上でサーバーサービスが動いている |
MACHINENAME<03> | 一般的なマシン名(NetBIOS名) |
MACHINENAME<20> | LanManサーバーサービスがMACHINENAMEで動いている |
WORKGROUP<1b> | ドメインマスターブラウザー |
Table 29.2. Group Names
WORKGROUP<03> | WORKGROUPのすべてのメンバーによって登録された一般的な名前 |
WORKGROUP<1c> | ドメインコントローラー/ネットログオンサーバー |
WORKGROUP<1d> | ローカルマスターブラウザー |
WORKGROUP<1e> | ブラウザー選定サービス |
すべてのNetBIOSマシンは、それに固有の名前を
一意なNetBIOS名と
グループ名単位で登録することに注意すべきである。
これは、システム管理者が、/etc/hosts
中か、DNSデータベース中で、
各IPアドレスに割り当てられる名前を決める伝統的な決め方をするTCP/IPでの流儀と
大きく異なる。
明確な説明の中の、1つの重要なポイントに注意すべきである。
/etc/hosts
ファイルとDNSレコードは、それが必要かもしれない
サービスのタイプを見つけることに、Microsoft Windowsクライアントが依存する、
NetBIOS名前情報を提供しない。これの例は、Microsoft Windowsクライアントが
ドメインログオンサーバーを捜そうとする時に起こる事である。クライアントは
名前タイプ*<1C>を登録しているすべてのマシンを列挙するために
(NetBIOSブロードキャスト経由で)検索を実行することによって、このサービスと、この
サービスを提供しているサーバーのIPアドレスを捜す。次にログオン要求は、IPアドレスの
一覧として返された各IPアドレスに送られる。どれかのマシンが最初に応答すると、
次にそのマシンがログオンサービスを提供することになる。
Microsoft Windows ネットワークのセキュリティアーキテクチャを示している付加的な意味を 持っているので、“ワークグループ”および“ドメイン”という 名前は、まったくもって紛らわしい。“ワークグループ”という単語は、 ネットワーク環境の基本原則がピアツーピア構造になっている事を示している。 ワークグループにおいては、すべてのマシンは、自分自身のセキュリティについて責任があり、 一般的にそのセキュリティは、パスワードの使用で制限される(共有レベルのセキュリティ として知られている)。ピアツーピアのネットワークを使うほとんどの場合、自分自身の マシンを制御するユーザーは単に全くセキュリティを持たないように(訳注:共有しないように) するだろう。ワークグループ環境でもユーザーレベルのセキュリティを使うことは可能で、 その場合、ユーザー名と対応するパスワードを使うことを要求する。
Microsoft Windowsネットワークは、ローカルとリモートマシンすべてでのメッセージ通信用の マシン名を使うために、前もって決定される。使われるプロトコルは、 Server Message Block (SMB)と呼ばれ、これはNetBIOSプロトコル (Network Basic Input/Output System)を使って実装される。NetBIOSはLLC (Logical Link Control)プロトコルを使ってカプセル化される。 この場合、結果のプロトコルはNetBEUI(Network Basic Extended User Interface)と呼ばれる。 NetBIOSは、Novell NetWareによって使われるIPX(Internetworking Packet Exchange)上でも 動作できる。また、TCP/IPプロトコル上でも動作でき、この場合、結果の プロトコルは、NBTあるいはNetBT、すなわちNetBIOS over TCP/IPと呼ばれる。
Microsoft Windows マシンは、たくさんの複雑な名前解決メカニズムを使う。主にTCP/IP で接続するので、このデモはその領域にのみ限っている。
すべてのMicrosoft Windowsマシンは、おおよそ過去10分から15分の間に通信したすべての 外部マシンのNetBIOS名とIPアドレスを格納する、メモリ中のバッファーを使う。設定された すべての名前解決機構を使って行うよりも、ローカルキャッシュからマシンのIPアドレスを 得る方がより効率的である。
もしも、ローカル名前キャッシュにその名前があるマシンが、キャッシュ上で満了になり 削除される前にシャットダウンした場合、そのマシンへメッセージ交換を行おうとすると、 そのマシンはタイムアウトするだろう。その名前がキャッシュにあるので、名前解決は 成功するが、マシンは反応しない。これは、ユーザーにとって不満を感じさせるが、これは プロトコルの特性である。
NetBIOS名前キャッシュの検査を行うMicrosoft Windows ユーティリティは、
“nbtstat”である。Sambaにおける同等品はnmblookup
である。
このファイルは通常Microsoft Windows NT 4.0かWindows 200x/XPのディレクトリ
%SystemRoot%\SYSTEM32\DRIVERS\ETC
にあり、IPアドレスとマシン名が
対になったものを含む。LMHOSTS
ファイルはNetBIOS名からIPアドレスへの
マッピングを行う。
典型的なものは以下の通り:
# Copyright (c) 1998 Microsoft Corp. # # This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS # over TCP/IP) stack for Windows98 # # This file contains the mappings of IP addresses to NT computer names # (NetBIOS) names. Each entry should be kept on an individual line. # The IP address should be placed in the first column followed by the # corresponding computer name. The address and the computer name # should be separated by at least one space or tab. The "#" character # is generally used to denote the start of a comment (see the exceptions # below). # # This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts # files and offers the following extensions: # # #PRE # #DOM:<domain> # #INCLUDE <filename> # #BEGIN_ALTERNATE # #END_ALTERNATE # \0xnn (non-printing character support) # # Following any entry in the file with the characters "#PRE" will cause # the entry to be preloaded into the name cache. By default, entries are # not preloaded, but are parsed only after dynamic name resolution fails. # # Following an entry with the "#DOM:<domain>" tag will associate the # entry with the domain specified by <domain>. This effects how the # browser and logon services behave in TCP/IP environments. To preload # the host name associated with #DOM entry, it is necessary to also add a # #PRE to the line. The <domain> is always pre-loaded although it will not # be shown when the name cache is viewed. # # Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) # software to seek the specified <filename> and parse it as if it were # local. <filename> is generally a UNC-based name, allowing a # centralized lmhosts file to be maintained on a server. # It is ALWAYS necessary to provide a mapping for the IP address of the # server prior to the #INCLUDE. This mapping must use the #PRE directive. # In addition the share "public" in the example below must be in the # LanMan Server list of "NullSessionShares" in order for client machines to # be able to read the lmhosts file successfully. This key is under # \machine\system\currentcontrolset\services\lanmanserver\ # parameters\nullsessionshares # in the registry. Simply add "public" to the list found there. # # The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE # statements to be grouped together. Any single successful include # will cause the group to succeed. # # Finally, non-printing characters can be embedded in mappings by # first surrounding the NetBIOS name in quotations, then using the # \0xnn notation to specify a hex value for a non-printing character. # # The following example illustrates all of these extensions: # # 102.54.94.97 rhino #PRE #DOM:networking #net group's DC # 102.54.94.102 "appname \0x14" #special app server # 102.54.94.123 popular #PRE #source server # 102.54.94.117 localsrv #PRE #needed for the include # # #BEGIN_ALTERNATE # #INCLUDE \\localsrv\public\lmhosts # #INCLUDE \\rhino\public\lmhosts # #END_ALTERNATE # # In the above example, the "appname" server contains a special # character in its name, the "popular" and "localsrv" server names are # pre-loaded, and the "rhino" server name is specified so it can be used # to later #INCLUDE a centrally maintained lmhosts file if the "localsrv" # system is unavailable. # # Note that the whole file is parsed including comments on each lookup, # so keeping the number of comments to a minimum will improve performance. # Therefore it is not advisable to simply add lmhosts file entries onto the # end of this file.
このファイルは、通常Microsoft Windows NT 4.0あるいはWindows 200x/XPの
ディレクトリ%SystemRoot%\SYSTEM32\DRIVERS\ETC
中にあり、
IPアドレスとIPホスト名が対になったものを含む。これは、名前解決機構として
使うことが出来るが、どのようにTCP/IP環境が設定されたかに依存する。このファイルは
UNIX/Linuxでの/etc/hosts
ファイルと同じ使い方である。
この機能は、ネットワーク設定機能中のTCP/IPに関する設定の中で設定できる。 もしもこれが有効になると、どのようにNetBIOSノードタイプパラメーターが設定 されたかに正確に依存して決まる、選択された名前解決シーケンスが後に続く。 ノードタイプ0は、NetBIOS名前キャッシュ中で名前検索をしても見つからなかった場合、 NetBIOSブロードキャスト(UDP上のブロードキャスト)が使われる。もしも、失敗した場合、 次にDNS、HOSTSとLMHOSTSが使われる。もしもノードタイプが8ならば、DNS,HOSTS,LMHOSTS の検索から結果を得る前に、NetBIOSユニキャスト(UDPユニキャストで)がWINSサーバーに 送られるか、ブロードキャスト検索が使われる。 This capability is configured in the TCP/IP setup area in the network configuration facility. If enabled, an elaborate name resolution sequence is followed, the precise nature of which is dependent on how the NetBIOS Node Type parameter is configured. A Node Type of 0 means that NetBIOS broadcast (over UDP broadcast) is used if the name that is the subject of a name lookup is not found in the NetBIOS name cache. If that fails, then DNS, HOSTS, and LMHOSTS are checked. If set to Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the WINS server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast lookup is used.
WINS(Windows Internet Name Server)サービスはrfc1001/1002で定義されたNBNS (NetBIOSネームサーバー)と同等のものである。WINSサーバーは、もしもTCP/IP設定で、 少なくとも1つのWINSサーバーのIPアドレスを指定したとき、Windows クライアントによって 登録される名前とIPアドレスを格納する。
SambaをWINSサーバーサーバーとして設定するには、以下のパラメーターをsmb.conf
ファイルに追加する必要がある:
wins support = Yes |
SambaをWINSサーバーを使うように設定するためには、以下のパラメーターをsmb.conf
ファイルに追加する必要がある:
wins support = No |
wins server = xxx.xxx.xxx.xxx |
ここで、xxx.xxx.xxx.xxx
は、WINSサーバーのIPアドレスである。
SambaをWINSサーバーとして設定するための情報は、 ネットワークブラウジングを参照のこと。
TCP/IPネットワーク設定の問題は、すべてのネットワーク管理者が遅かれ早かれ直面する。 原因は、キーボード入力の問題から、単純なケアレスミスまで多様である。もちろん、 誰もが常時不注意であるというわけではない!
“WindowsからSambaサーバーにpingが出来るが、SambaサーバーからWindowsにpingが できない。”
WindowsマシンはIPアドレスが192.168.1.2で、ネットマスクが255.255.255.0であり、 Sambaサーバー(Linux)はIPアドレスが192.168.1.130で、ネットマスクが 255.255.255.128である。マシンはローカルネットワーク上にあり、その他の外部 接続はない。
整合していないネットマスクのため、Windowsマシンは、ネットワーク192.168.1.0/24上に いて、Sambaサーバーはネットワーク192.168.1.128/25にいる。 これは論理的に異なったネットワークである。
遅いネットワークという共通の問題には以下がある:
クライアントがDNSを使うように設定されていて、DNSサーバーがダウンしている。
クライアントがリモートのDNSサーバーサーバーを使うように設定されているが、 リモート接続がダウンしている。
クライアントがWINSサーバーを使うように設定されているが、 WINSサーバーがない。
クライアントがWINSサーバーを使うように設定されていないが、 WINSサーバーがある。
ファイアウォールがDNSかWINSトラフィックを制限している。
“Sambaサーバーの名前が変わり、Sambaが再起動した後、Sambaサーバーへ、新しい 名前で、Microsoft Windows NT4ワークステーションからpingが出来ない。しかし、 古い名前でのpingは引き続き出来るなぜ?”
この説明から、以下の3つが明白となる:
WINSが使われていないブロードキャストベースの名前解決のみ使われている。
Sambaサーバーが改名されて再起動したのが10分か15分前以内である。
古いSambaサーバー名が、まだMicrosoft Windows NT4 ワークステーション 上のNetBIOS名前キャッシュ中にある。
Microsoft Windows NT4マシン上のNetBIOS名前キャッシュ中に、どの名前が存在して
いるかを調べるには、cmd
シェルを開き、以下を行う:
C:\>
nbtstat -n
NetBIOS Local Name Table Name Type Status ------------------------------------------------ FRODO <03> UNIQUE Registered ADMINISTRATOR <03> UNIQUE Registered FRODO <00> UNIQUE Registered SARDON <00> GROUP Registered FRODO <20> UNIQUE Registered FRODO <1F> UNIQUE RegisteredC:\>
nbtstat -c NetBIOS Remote Cache Name Table Name Type Host Address Life [sec] -------------------------------------------------------------- GANDALF <20> UNIQUE 192.168.1.1 240C:\>
この例では、GANDALFがSambaサーバーでFRODO が、Microsoft Windows NT4 ワークステーションである。 最初の行は、ローカル名前テーブルの内容を示していて(すなわち、Microsoft Windows ワークステーションとして識別される)、2行目はNetBIOS名前キャッシュ中に あるNetBIOS名を示している。 名前キャッシュ中にはこのワークステーションの名前として知られているリモートマシン を含んでいる。
Table of Contents
どんな技術もいつかは成熟する。ここ10年間に焦点を当てたときに、成熟度が大きく 前進した領域のひとつが、どこでもだれでもコンピュータを利用できるようにする ための技術である。もっとも、常にそうだったわけではない。実際、ソフトウェアを 開発する際には、作成した国でのみ使うことを想定して開発されるのが当たり前だった のはさほど昔のことではない。
すべてのコンピュータユーザーに自国の言語サポートを提供するために使われたすべての労力、 Openi18n organizationの労力は、 特記に値する。 Of all the effort that has been brought to bear on providing native language support for all computer users, the efforts of the Openi18n organization is deserving of special mention.
Samba-2.xは、codepagesと呼ばれる単一のロケール機構をサポート していた。Samba-3では真に国際的な、ファイルと印刷共有プラットフォームとして 予定されていた。
コンピュータは数字で通信する。テキストにおいては、各数字は対応する文字に変換される。 特定の数に割り当てられた意味は、使用する文字セット(charset)に 依存する。
文字セットは数字から文字への変換のために使われる表として見る事ができる。 すべてのコンピュータが同じ文字セット(ドイツのウムラウト、日本の文字セットなど)を 使うわけではない。American Standard Code for Information Interchange (ASCII) エンコーディングシステムは、現在まで、コンピュータによって使われる基本の文字 エンコーディング体系となっていた。これは、256文字を含む文字セットを使用する。 このモードのエンコーディングを使うと、各文字は正確に1バイトとなる。
ASCIIエンコーディングが取るよりも、少なくとも2倍の、より多くの記憶容量を必要とする、
拡張文字をサポートする文字セットもある。そのような文字セットは、考えられるすべての
文字よりも多い256 * 256 = 65536
文字を含むことが出来る。これらは、
1つの文字を格納するために、1バイトより多く使うという理由で、マルチバイト文字セットと
呼ばれる。
ある標準化されたマルチバイト文字セットエンコーディング機構は、 ユニコードである。 マルチバイト文字セットを使う大きな利点は、それを使うだけで済むと言うことである。 通信時に、2つのコンピュータが尾内文字セットを使うようにする必要はない。
古いWindowsクライアントはMicrosoftによるコードページ
という
単一バイト文字セットを使っている。しかし、SMB/CIFSプロトコル中で使われるために
調停される文字セットではサポートされていない。そのため、より古いクライアントと通信
する時、同じ文字セットを使うようにしなければならない。より新しいクライアント
(Windows NT、200x、XP)では、ユニコードを使って通信する。
Samba-3では、Sambaはユニコードで通信できる。内部的には、Sambaは3つの文字セットを 認識する。
これは使用しているOSによって内部的に使われる文字セットである。
既定値はUTF-8
で、ほとんどのシステムに適しており、
すべての言語中のすべての文字をカバーする。以前のSambaリリースにおける
既定値は、クライアントのエンコーディングでファイル名を保存するための
ものであった。たとえば、CP850は西ヨーロッパ各国用である。
これは、画面上でメッセージを表示するためにSambaが使う
文字セットである。これは一般的にunix charset
と
同じにすべきである。
これは、DOSとWindows 9x/Meクライアントと通信する時に
Sambaが使う文字セットである。より新しいクライアントすべてとはユニコードで
通信する。既定値は、インストールした、使用するシステム上の文字セットに
依存する。使用するすシステム上での既定値が何かと言うことは、
testparm -v | grep "dos charset"
を実行して
調べられる。
以前のSambaバージョンは、何らの文字セット変換を行わないので、ファイル名中の文字セットは、 通常UNIX文字セットでは正しくならない。DOS/Windowsクライアントによって使われるローカル 文字セット専用である。
Bjoern Jackeは、convmvという、 1つのコマンドですべてのディレクトリ構造を異なった文字セットに変換できるユーティリティを 作成した。
日本語の文字セットを設定するのはかなり難しい。それは以下のような理由による:
Windows文字セットはオリジナルの日本工業標準(JIS X 0208)から拡張された ものであり、標準化されていない。これは、正確に標準にそった実装は、 Windows文字セット全部をサポート出来ないと言うことである。
主に歴史的な理由により、日本においては複数のエンコーディング方法があり、 おのおのは、互いに完全に互換ではない。主要なエンコーディング方法は2つ ある。1つはWindowsといくつかのUNIXで使われるシフトJIS系列である。 もう1つはEUC-JP系列であり、ほとんどのUNIXとLinuxで使われている。さらに、 Sambaは以前に、CAPとHEXという、CAP/NetAtalkと日本語ファイル名を使えない UNIXとの互換性を確保するための、固有なエンコーディング方法を提供して いた。EUC-JP系列のいくつかの実装は、完全なWindows文字セットをサポート できない。
ユニコードと旧来の日本語文字セットとの間での変換テーブルは いくつかある。ある1つはWindowsと互換であり、そのほかはユニコード コンソーシアムのものをベースにしたものであり、ほかには複数のものを まぜた実装がある。ユニコードコンソーシアムは、公式にはユニコードと 他の旧来の文字セットとの間での変換テーブルを定義していないので、 それは標準にはなり得ない。
iconv()内で有効な文字セットと変換テーブルは、利用できるiconv ライブラリに依存する。その次に、日本語のロケール名は異なったシステム上 では異なっているかもしれない。これは、文字セットパラメーターの値は、 使用しているiconv()の実装に依存するというということである。
2バイトの固定的なUCS-2エンコーディングがWindows内部で使われているが、 シフトJIS系列のエンコーディングは、英語環境でASCIIエンコーディングが 使われているように日本語環境で通常使われている。
dos charsetとdisplay charsetは ロケールと互換のある文字セットとWindows上で使われているエンコーディング方法に 設定すべきである。これは通常CP932であるが、時々違う名前を使う。
unix charsetはシフトJIS系列、EUC-JP系列、あるいは UTF-8系列に設定できる。UTF-8は常時利用可能であるが、他のロケールとそれ自身の 名前の有効性は使用するシステム依存である。
さらに追加すると、Samba 2.2系列において、“coding system = CAP” と設定したのと同じ事を行うvfs capモジュールを使うことによって、 シフトJIS系列をunix charsetパラメーターの値として 使うことを考慮することが出来る。
unix charsetをどこに設定するかは難しい質問である。 以下は特定の値を使う場合の詳細、利点、欠点の一覧である。
シフトJIS系列は日本語のWindows上で標準として使われている
Shift_JIS
と同等なロケールを意味する。
Shift_JIS
の場合は、たとえば、もしも
日本語のファイル名に0x8ba4 と 0x974c(4バイトの日本語文字列で、
“share”(訳注:“共有”)と
“.txt”が含まれていてSamba上にWindowsから書き込み
された場合、UNIX上のファイル名は
0x8ba4, 0x974c, “.txt”(8バイトのバイナリ文字列)
となり、これはWindowsのものと同じである。
シフトJIS系列が、いくつかの商用ベースのUNIX、たとえば hp-uxとAIXで、日本語のロケールで使われている(しかし、 EUC-JPロケール系列を使うことも可能である)。それらのプラット フォーム上でシフトJISを使うと、Windowsから作成された 日本語のファイル名はUNIX上でも参照できる。
もしも、使用しているUNIXがすでにシフトJISで動いていて、Windowsから 書かれる日本語ファイル名を使う事が必要なユーザーには、シフトJIS系列 は最適の選択である。しかし、不正なファイル名が表示されるか、 非ASCIIファイル名を扱えないコマンドがファイル名を処理するときに アボートするかもしれない。そして、ファイル名中に、注意して 扱わなければならない“\ (0x5c)”があるときは特に である。UNIX上でWindowsから書かれたファイル名をさわらないのが 最も安全である。
ほとんどの日本語化されたフリーソフトウェアは実際EUC-JPのみで 動作する。日本語化されたフリーソフトウエアがシフトJISで動くかを 検証するのはよい習慣である。
EUC-JP系列は、日本でのUNIX(EUCには日本語以外の言語、たとえば EUC-KRの仕様も含む)で広く使われているEUC-JPという業界標準と同等の ロケールを意味する。EUC-JP系列の場合、例えば、もしも、日本語の ファイル名に0x8ba4と0x974cと“.txt”を含むものが、 Samba上でWindowsから書かれた場合、UNIX上のファイル名は、 0xb6a6, 0xcdad,“.txt”となる(8バイトのバイナリ文字列)。
EUC-JPは通常オープンソースのUNIX、Linuxと振りと商用ベースのUNIX、 Solaris、IRIXとTru64 UNIXで日本語ロケールとして使われている (しかし、SolarisではシフトJISとUTF-8を使うことも出来、Tru64 UNIX ではシフトJISも使うことが出来る)。EUC-JP系列を使うためには、 Windowsから作成された日本語ファイル名の大半は、UNIX上でも参照 できる。また、ほとんどの日本語化されたフリーソフトウェアも ほとんどがEUC-JPのみで動作する。
UNIX上で日本語のファイル名を使うときにはEUC-JP系列を選択する 事を推奨する。
“\ (0x5c)”のように注意深く扱わなければならない文字が 無いにもかかわらず、不正なファイル名が表示されることもあり、 非ASCIIファイル名を扱えないいくつかのコマンドはファイル名の 処理中にアボートするかもしれない。
さらに、もしも、異なる、インストールされたlibiconvを使ってSambaを 構築した場合、eucJP-msロケールがlibiconv中に含まれ、OSに 含まれているEUC-JP系列とは非互換かもしれない。この場合、 ファイル名に非互換の文字を使うことを防止する必要があるかもしれない。
UTF-8は、ユニコードコンソーシアムによって定義された国際標準である
UTF-8と同じロケールであることを意味する。UTF-8中では、
文字
は1から3バイトで記述される。日本語
では、ほとんどの文字は3バイトとなる。WindowsのシフトJISでは、
日本語を表現する文字が、1か2バイトなので、UTF-8の文字列長は、
オリジナルのシフトJISの文字列の1.5倍である。UTF-8の場合、
たとえばSamba上に、Windowsから書かれるファイル名が、
0x8ba4と0x974cと“.txt”の場合、UNIX上のファイル名は、
0xe585, 0xb1e6, 0x9c89, “.txt”(10バイトのバイナリ
文字列)となる。
iconv()が有効でないシステムか、iconv()のロケールがWindowsと 非互換のものの場合、UTF-8は唯一の有効なロケールである。
日本においてはUTF-8を既定値のロケールとしているシステムはない。
何らかの不正なファイル名が表示されるかもしれず、非ASCII ファイル名を扱えないコマンドがあるかもしれない。特に、 ファイル名に注意深く扱わなければならない “\ (0x5c)”をファイル名に持つ場合は、UNIX上で、 Windowsから書かれたファイル名に触れない方が無難である。
さらに追加すると、Sambaに直接関係してはいないが、 一般的にUNIX上で使われているiconv()機能と、WindowsやJavaの ような他のプラットフォーム上で使われている機能との間では、 微妙な違いがあり、そのためシフトJISとユニコードのUTF-8との 間での変換は注意深くかつ、プロセスで関連する制限の認識を して行わなければならないという点で関連性がある。
Mac OS Xはそのファイル名のエンコード方式としてUTF-8を使用しているが、 それはSambaが扱えない拡張されたUTF-8仕様を使っているので、Mac OS X では、UTF-8ロケールは無効である。
CAPエンコーディングは、Macintosh用のファイルサーバーソフトウェア であるCAPとNetAtalkで使われる仕様である。CAPエンコーディングの 場合、たとえば、もしもSamba上に、Windowsから書かれる日本語の ファイル名に、0x8ba4と0x974cと“.txt”が含まれている 場合、UNIX上のファイル名は“:8b:a4:97L.txt” (14バイトのASCII文字列)となる。
CAPエンコーディングでは、ASCII文字として表現できないもの (0x80以上)は、“:xx”形式でエンコードされる。 ファイル名中に“\(0x5c)”を含むものは注意深く扱う 必要があるが、非ASCIIファイル名を扱えないシステム中でも、 ファイル名が不正になることはない。
CAPエンコーディングのとても大きな利点は、CAPあるいはNetAtalkでの エンコーディングと互換があるということである。これらは、それぞれ Columbia Appletalk ProtocolとNetAtalkオープンソースソフトウェア プロジェクトである。これらのソフトウェアアプリケーションが、 CAPエンコーディングでUNIX上にファイル名を書き込むので、もしも、 SambaとNetAtalkの両方でディレクトリが共有される場合、非ASCII ファイル名を使わないようにCAPを使って、ファイル名が不正になる ことを防ぐ必要がある。
しかし、最近、NetAtalkはファイル名をEUC-JP(すなわち、日本の オリジナルなVine Linux)でファイル名を書き込むように、いくつかの システムではパッチが当てられた。この場合、CAPエンコーディングの 代わりに、EUC-JP系列を選ばなければならない。
vfs_cap それ自身は、非ASCII文字を扱えないシステムか、NetAtalkと ファイルを共有するシステムのための、非シフトJIS系列のロケールの ために有効である。
Samba-3でCAPエンコーディングを使うためには、unix charset パラメーターと、 the VFS CAP smb.conf file のようなVFSを使うべきである。 To use CAP encoding on Samba-3, you should use the unix charset parameter and VFS as in VFS CAPを使うsmb.confファイル。
もしも、GNU libiconvをunix charsetに使うならば、CP932を設定 である。この設定を使う場合、“cap-share”共有中の ファイル名はCAPエンコーディングで書かれる。
個別の実装に関する追加情報は以下の通り:
日本語を正しく取り扱うために、libiconv-1.8に libiconv-1.8-cp932-patch.diff.gz というパッチを適用すべきである。
パッチを当てたlibiconv-1.8を使うことで、以下の設定が有効になる:
dos charset = CP932 unix charset = CP932 / eucJP-ms / UTF-8 | | | +-- EUC-JP系列 +-- Shift_JIS系列 display charset = CP932
他の日本語ロケール(たとえば、Shift_JISとEUC-JP)は、Windowsとの 互換性が欠如しているため、使うべきではない。
日本語を正しく取り扱うために、glibc-2.2.5/2.3.1/2.3.2に patch のパッチを適用すべきであり、そうでない場合は、パッチがマージ された、glibc-2.3.3以降を使うべきである。
上記のglibcを使うことで、以下の設定が有効になる:
dos charset = CP932 |
unix charset = CP932 / eucJP-ms / UTF-8 |
display charset = CP932 |
他の日本語ロケール(たとえば、Shift_JISとEUC-JP)は、Windowsとの 互換性が欠如しているため、使うべきではない。
Samba 2.2系列以前では、“coding system”パラメーターが使われていた。Samba 2.xの 既定値のcodepageは code page 850であった。Samba-3系列では、これは unix charsetに置き換えられた。 Samba-2.2とSamba-3中の日本語文字セット には、Samba-2.2系列からSamba-3系列へ移行するときのマッピングテーブルを示している。
“SambaがCP850.so
ファイルがないというエラーを出す。”
CP850はdos charsetの既定値である。 dos charsetは使用しているDOSクライアントにょって 使われるコードページに変換するのに使われる。もしも、DOSクライアントが ないのであれば、このメッセージを無視しても安全である。
CP850は使用しているローカルなiconvの実装によってサポートされている。
必要とするすべてのパッケージがインストールされているかを確認すること。
もしもソースからSambaをコンパイルした場合、configureにおいてiconvを
見つけたかを確認すること。これは、configure
が
実行された的に生成されるconfig.log
ファイルを
チェックすることで行える。
Samba プロジェクトは 10 才を超えている。 Samba の歴史の初期のころ、 UNIX の管理者はその重要な実装者であった。 UNIX 管理者は UNIX システムツール を使って UNIX システムファイルをバックアップしている。 過去 4 年間にわたって増加している Microsoft ネットワーク管理者は、 Samba に 興味を持っている。 このことは、 Samba メーリングリスト上のバックアップについての質問に反映され ている。
Microsoft Windows トレーニングコースで議論されている間、 親 UNIX 派の代表一人が Windows NT4 が UNIX に比べ限定されていることを 指摘してクラスを驚かせた。 彼は UNIX をメカノセット (訳注:組立玩具。穴が空いた様々な形をした板を、 ボルトとナットで組み合わせて様々な形を作る) に例えた。シンプル、効率的、 で、組み合わせれば、望まれるいかなる成果への到達性がある、無限の道具 である。
Windows ネットワーク擁護者の一人が反論した。 もしメカノセットを望むなら購入しただろう。 しかし、複雑な単独のツールが、彼女のような人たちによってより好まれる。 求められる以上のことを行うが、明らかな用途と意図によってなされるためだ。
ここにある情報は、あるがままでかつ適合性や適切さの推奨をしているものではないこと に注意すること。ネットワーク管理者は、どんなバックアップソリューションを構築す る前にも、無償か商用のソフトウェアのいずれも相当な注意による調査を実行することが 奨励される。
あなたが参照したいと思うだろう有用な Web サイトを最近偶然見つけた。 場所は www.allmerchants.comである。
以下の3つのフリーソフトウェアプロジェクトもまた考えてみる価値があるだろう。
BackupPC バージョン 2.0.0
は SourceForge で
リリースされている。新しい機能は
rsync/rsyncd
のサポートと CGI インタフェースの国際
化 (英語、フランス語、スペイン語とドイツ語を含む) を含む。
BackupPC は Linux 、 UNIX と Windows PC とラップトップからサーバーまで
をバックアップするための Perl ベースのハイパフォーマンスパッケージで
ある。
BackupPC は高度な設定が可能でインストールと保守が簡単である。
クライアントデータを引き出すために (smbclient を通して) SMB 、
tar
over rsh/ssh
、または
rsync/rsyncd
が使用される。
ディスクと RAID システムのコストの減少によって、サーバーのローカルディスク やネットワークストレージに多数のマシンのバックアップを行うことが実用的、 効果的になった。 BackupPC はこれを行う。
重要な特徴は、同一ファイルのプーリング (サーバーのディスクスペースの多大 なる倹約) 、圧縮、そしてバックアップのブラウズとリストアができ る包括的な CGI インタフェースである。
BackupPC は GNU GPL ライセンスで配布されるフリーソフトウェアである。 BackupPC サーバーが Linux/UNIX/freenix で動作する。またクライアントは Linux 、 UNIX 、 Windows 9x/Me/200x/XP と Mac OSX でテストされた。
rsync
は、ファイルやディレクトリツリーを効率的にコ
ピーする柔軟なプログラムである。
rsync
は、どのファイルをコピーするのか、どのよ
うに転送するかを設定するための多数のオプションがある。 rsync は
ftp, http, scp
、または rcp
の
代替として使われるかもしれない。
rsync リモートアップデートプロトコルによって、 rsync は 2 つのファイル の差分のみをネットワークを通して転送することができる。 rsync パッケージに同梱されているテクニカルレポートに説明されている効 率的なチェックサム検索アルゴリズムを利用している。
rsync のその他の特徴
リンク、デバイスファイル、所有者、グループ、パーミッション のコピーをサポート。
GNU tar に似た exclude と exclude-from オプション。
CVS がするように同じファイルを無視する CVS exclude モード。
透過的なリモートシェルの利用。 rsh と ssh を含む。
root 権限を要求しない。
待ち時間による損失を最小化するためにファイル転送のパイプライン化。
匿名または認証された rsync サーバーのサポート (ミラーリング に理想的)。
Amanda (the Advanced Maryland Automatic Network Disk Archiver) は、 複数のホストを単一の大きな容量のテープドライブへバックアップするための 単一のマスターバックアップサーバーを LAN 管理者がセットアップできる バックアップシステムである。 Amanda はシステム付属の dump と GNU tar を両方または片方を使い、様々な バージョンの UNIX が稼働する多数のワークステーションをバックアップする ことができる。最新のバージョンでは Samba を使って Microsoft Windows ホ ストをバックアップすることも可能である。
Amanda に関するさらなる情報は、 www.amanda.org/ サイト を参照すること。
Browseable Online Backup System (BOBS) は一揃いのオンラインバックアッ プシステムである。 大きなディスクをバックアップを格納するために利用する。 Web ブラウザーを 利用してファイルをブラウズすることができる。 AppleDouble とアイコンファイルのような特殊なファイルを取り扱うことができる。
BOBS のホームページは bobs.sourceforge.net である。
Table of Contents
ネットワーク管理者は、しばしばファイルと印刷サービスの可用性について関心を持っている。 ネットワークユーザーは、きわめて重要な、責任ある仕事を遂行するのに依存するサービスに 対して、厳しい態度をとりがちである。
コンピュータルームにある以下の標語が、スタッフに自らの責任を思い起こさせるのであった。 それは以下のようなものであった:
すべての人間は過ちを犯すものである。大小を問わず、我々は絶えず過ちを犯している。 機会も同様に故障するものである。コンピュータは人によって管理される機械であり、 故障の結果は悲惨なものとなりうる。管理者の責任は、故障に対処し、故障を予測し、 人知の及ぶ限り、かつ経済的に合理的な範囲でその可能性を抹消することに他ならない。 あなたの行動は、問題の一部となるか、それとも解決の一部となるか。
もしも、計画的、生産的な方法で障害に対処するのであれば、まず最初に問題を理解する 必要がある。それがこの章の目的である。
以下の議論には障害に対抗するためにネットワーク基盤をどのように展開すべきかについての ポイントとなる情報も含まれている。ただし、ここでの目的は、高可用性に関する長大な論文を 発表することではない。そのため、高可用性を提供するソリューションの具体的な実例は提示 していない。Samba を含む CIFS/SMB 技術を展開する際に適用するための、高可用性に関する 最新の知識とノウハウの紹介を主眼に置いた詳細なドキュメントの作成に誰か が挑戦してくれることを期待して、ここでの記述は概論に留める判断を行っている。
以下の要約は、2003年4月に、ドイツのゲッティンンゲンで行われた、SambaXP 2003 カンファレンスで、Jeremy Allisonによって行われた発表の一部である。 素材となる情報は、幾つか追加されているが、それらを以下の構成に まとめあげたのは、Jeremy ならではである。
すべてのクラスターリング技術は以下の1つあるいはそれ以上を達成することを目的としている:
コンピュータの能力を最大限使えること。
より高速なプロトコル実行を行うこと。
無停止サービスを提供すること。
単一障害点を避けること。
資源を最も効果的に使うこと。
クラスター化されたファイルサーバーは理想的に以下の属性を有している:
すべてのクライアントはどのサーバーにも透過的に接続できる。
サーバーが故障するとクライアントは透過的に他のサーバーに再接続できる。
すべてのサーバーは、同じファイル群を提供する。
すべてのファイルの変更は、すべてのサーバーで直接行われるように見える。
分散ファイルシステムが必要。
より多くのサーバーやディスクを追加することで、無限に拡張できる。
簡単に言うと、問題は状態(state)にある。
1つの名前と1つのIPアドレスを持つ単一のサーバーのように、ファイルサーバーの クラスターを見せるためにすることは可能で、クライアントから受信した TCPデータストリームはフロントエンドの仮想サーバーによって処理される必要が ある。このサーバーはSMBプロトコルレイヤレベルで、入力したパケットを分割し、 次に、クラスター中の異なったサーバーにSMBパケットを中継する。
印刷とユーザー検索要求を扱うためには、すべてのIPC$接続とRPC呼び出しを1台の サーバーに振り分けるしかない。RPC印刷ハンドルは、異なったIPC$ セッションで共有される。これをクラスターを構成するサーバー間で 分割するのは難しい!
概念的に、他のすべてのサーバーはファイルサービスのみ提供する。これは 集中させるよりも簡単な問題である。
SMBリクエストを分割する事は、SMBステート情報を知っていることが要求され、そのすべては フロントエンドの仮想サーバーによって保持されねばならない。 これは解決するのには複雑で難しい問題である。
Windows XPとその後継は、その意味を変更し、そのため、ステート情報 (vuid,tid,fid)は操作が成功するために一致しなければならない。これは、 以前よりも物事を単純にし、前へ進むためのよい一歩である。
SMBリクエストは、それに対応するサーバーにvuidによって送られる。 このソリューションを作り出すコードは現在存在しない。この問題は、 Samba中で、Windows 2000ターミナルサーバーからの複数のリクエストからの リクエストを正しく処理する問題と、概念的に似ている。
UNIXとLinux用に、たくさんの分散ファイルシステムがある。
SMB文法を認識することを、ずっと心にとめている間は、我々のクラスターの バックエンドに多くが適用できる(共有モード、ロックとoplock問題は特に)。 一般的な自由に使える分散ファイルシステムには以下がある: Many could be adopted to backend our cluster, so long as awareness of SMB semantics is kept in mind (share modes, locking, and oplock issues in particular). Common free distributed file systems include:
NFS
AFS
OpenGFS
Lustre
サーバープール(クラスター)は、もしもすべてのSMB文法がそのプール内で実行出来るならば、 任意の分散ファイルシステムを使える。
クラスター化されたサーバーが純粋なSMBサービスを提供するとき、oplockの 処理は、バックエンドのファイルシステムプールに渡す必要性はなく、 サーバープール内で完結してもよい。
他方、サーバープールがNFSや他のファイルサービスをも提供する場合、 SMBサービスと相互運用できるように、oplockを認識する実装は基本である。 これは、現在有意義な挑戦である。これの相互運用性の提供に失敗すると、 Microsoft Windows クライアントのユーザーによってはっきりと気がつく 明確な性能の低下をもたらす。
最後に、すべてのステート情報は、サーバープール間で共有されるべきである。
ほとんどのバックエンドファイルシステムは、POSIXファイルシステムを サポートしている。これは、SMB文法をファイルシステム中で使うことを 困難にしている。POSIXのロック機構は、SMBのロック機構とは異なる 属性と文法である。
サーバープール中のすべてのsmbd
プロセスはごく短時間に
通信しなければならない。このため、Sambaが使う現在の
tdb
ファイル構造はネットワーク間で使うのには
適していない。クラスター化されたsmbd
は何らかの、
他のものを使う必要がある。
サーバープール内の高速サーバー間通信は、完全に機能するシステムのために あらかじめ必要な機能である。これを可能にするものは以下のものがある:
商用の共有メモリバス(例:MyrinetまたはSCI [scalable coherent interface])。 これはとても価格が高い。
ギガビットイーサネット(現在簡単に使える)。
生のイーサネットフレーミング(TCPとUDPのオーバーヘッドをバイパス)。
これらの機能を有効化する効果の有無を計るパフォーマンス指標はまだ確立していない。
Sambaは、透過的なフィルオーバークラスターが出来るように、高速サーバー間接続システムで 動くように、明確に修正する必要がある。
影響を受けると思われるSamba内の特定の機能は以下の通り:
フェイルオーバーサーバーにエクスポートされたファイルシステム内で異なった機能を 扱えるようにすることは、分散ロッキングプロトコルを要求する問題をなくす。
もしも、ペアの中で1つのサーバーのみアクティブである場合、高速サーバー間通信の必要性は 無くなる。この場合、新しいものを開発する代わりに、既存の高可用性ソリューションが 使える。これはかなりのコストがかかる単純なソリューションである。 そのコストとは、より複雑なファイル名空間を管理する必要があるということである。 単一のファイルシステムではないため、管理者はすべてのサービスがどこに配置されて いるかを覚えておかなければならない。複雑さは、扱うのが容易ではない。
仮想サーバーは、バックエンドサーバーに要求をリダイレクトする ため、引き続き必要である。バックエンドファイル空間の完全性は管理者の責任である。
フェイルオーバーサーバーはリソースのフェイルオーバーを扱うために通信する必要がある。 これは高可用性サービスでは基本である。専用のハートビートを使うことは、 フェイルオーバープロセスで、ある種の自立性を導入する、一般的な技術である。 これは、しばしは専用のリンク(LANまたはシリアル通信)上で行われる。
多くのフェイルオーバーソリューション(Red HatクラスターマネージャとMicrosoft Wolfpack のような)はフェイルオーバー通信のためにファイバチャネルディスクストレージアレイ をSCSIで共有して使える。Sambaに対するRed Hat高可用性ソリューションについての 情報は、 www.redhat.com で得られる。
Linux高可用性プロジェクトは、高可用性Sambaファイルサーバーソリューションを構築 したいならば、考慮するに値するリソースである。 www.linux-ha.org/にある ホームページを見てほしい。
フロントエンドサーバーの複雑性は、すべてのネットワーククライアントに対して、 サービスの継続性を同時に提供する間、バックエンドの障害をうまく扱わなければ ならないという理由で、高可用性に対する挑戦の余地がある。
1ディレクトリあたり10 万またはそれ以上のファイルを 必要とするアプリケーションを、バージョン 3 系の Sambaで利用すること には問題があり、それによって発生するパフォーマンス劣化を経験しているサイトがあ る。 Samba 3.0.12以降ではその解決策を実装している。
要求されている最新のリストだけを読むようにディレクトリの取扱いを修正した ことが鍵だった。 これとは違い、古い (Samba 3.0.11 までの) 振る舞いでは、 事前にディレクトリをすべてメモリへ読み込んでから名前を小出しにしていた。 通常では、これは とても奇妙な削除動作を持つ OS/2 アプリケーションを誤動作させる だろう。しかし、 Samba 4 (ありがとう Tridge) から流用したロジックにより、 3.0.12 の最新のコードでは、これを正しく取り扱う。
ディレクトリあたりに多数のファイルを必要とするアプリケーションを、パフォーマン スへ著しい影響を与えないように、セットアップするために以下の手順を実施する。
最初に、ディレクトリ中のファイルをすべて大文字または小文字 好きな方 (すでにすべてのファイルが大文字になっていたため大文字を私は選んだ) のどちらか のみに正規化する。 そして、このアプリケーションのために新しくおあつらえ向きの 共有を以下のように作成する。
[bigshare] |
path = /data/manyfilesdir |
read only = no |
case sensitive = True |
default case = upper |
preserve case = no |
short preserve case = no |
もちろん、あなた自身固有のパスと設定を使うこと。そして、ケースオプションはディレク トリのすべてのファイルに適合するように設定すること。 パスは、アプリケーションが必要とする大きなディレクトリを指さなければならない。 そのディレクトリとそれ以下のすべてのディレクトリの下に作られる新し いファイルはすべて smbd によって大文字に強制される。しかし smbd はもはや名前 のために走査する必要がなくなる。大文字で存在しなければまったく存在しないこと がわかるため。
極意は実に case sensitive = True 行にある。
これは、 smbd にその名前の大小文字が混在したバージョンを走査する必要が絶対
にないことを告げる。だから、アプリケーションが FOO
と呼ば
れるファイルを要求した場合、 stat コールにて見つからなかったら、 smbd は直ちに
file not found を返却する。違うケースのバージョンを走査することはない。
その他の xxx case xxx
行は、 smbd によって作成される
ファイルが一貫したケースに強制することでこれが機能するようにしている。
smb.conf
のこのセクションに付随して path
配下のすべ
てのファイルとディレクトリは大文字でなければならないことを忘れないこと。
何故ならこの設定では、 smbd は小文字のファイル名を見つけることができなくなる
からである。
このパラメーターは、問題のある振る舞いの (多数のエントリをもつディレクトリを使用
する) アプリケーションにへ提供する共有にのみ設定が許されているので、これらは
共有ごとになされることに注意すること 残りの smbd 共有は、影響を
受ける必要はない。
以上の設定は、大きなディレクトリを処理する際にsmbd をずっと速くさせる。私の テストケースでは 10 万を超えるファイルで smbd は今やとても効率的に処理する。
Table of Contents
この本の最初の版のリリース以来、Samba以外の事についてネットワーク管理者の手助けとなる かもしれない設定テクニックのよりよい資料について、繰り返し要求があった。一部の ユーザーは、include = file-nameパラメーターの使い方に 関連する文書を提供した。
2004年の中頃に始まったが、1つのマシン上で複数のSambaサーバーをホスティングする 機能について、関心が高まってきた。1つのサーバー上複数のSambaサーバーの振る舞いを ホスティングする事への興味も増えてきた。
テクニカルレビューワからのフィードバックによりこの章を含める必要が出た。 そのため、今まで十分に言及してこなかった質問への答えををここに記す。さらに、 この章を充実させる、利用者からの追加は歓迎する。ここで提供されているものは、 まったくもって、小さなとっかかりである。
単一のSambaサーバー上で複数のサーバーをホスト出来る方法はいくつもある。複数のサーバー ホスティングは1つのマシン上で複数のドメインをホストする事を可能にする。そのような 各マシンは独立していて、他に影響を与えずに、起動/停止ができる。
時には、各サーバーが固有のセキュリティモードを持つ、複数のサーバーをホスティングする ことが好ましいことがある。例えば、一般的な匿名印刷サーバーのように、単一のUNIX/Linux ホストはドメインメンバーサーバー(DMS)になれる。この場合、ドメインメンバーマシンとドメイン ユーザーはDMSにアクセスでき、さらにゲストユーザーでさえも、一般的な印刷サーバーにアクセス できる。他の、汎用(匿名)サーバーをホスティングするのに便利かもしれないシチュエーションの 例としては、CDROMサーバーのホスティングがある。
いくつかの環境では、固有のリソースを持つ、特定のユーザーかグループのみからアクセス可能な、 分離されたサーバーを持つ必要が規定されている。これは、Sambaが多数の物理的なサーバーを、 1つのSambaサーバーに置き換えられる、単純で、とても効果的な方法の1つである。
複数のサーバーホスティングの使用は、それぞれ個別の設定ファイルを持っている、複数の分離
されたSambaインスタンスを動かす必要がある。この方法は、各nmbd, smbd と winbindd
のインスタンスは、完全に分離されたTDBファイルへの書き込みアクセスが出来なければならない
という理由で、とても複雑である。nmbd, smbd と winbinddが使うTDBファイルを分離
させる事は、ホスティングを行う各Sambaを再コンパイルすることで、各Sambaが、固有のTDB
ファイルに対する既定値のディレクトリを持つか、nmbd, smbd と winbinddの
各インスタンスが、それらの固有のsmb.conf
設定ファイルで起動するようにしなければ
ならない、smb.conf
ファイルを設定することで可能となる。
各インスタンスは固有のIPアドレス(独立したIPアドレスはIPエイリアスで行える)で操作される べきである。nmbd, smbd とwinbinddの各インスタンスは、その固有IPソケットのみを リッスンすべきである。これはsocket addressパラメーターを使うことに よって、安全に出来る。Sambaサーバーの各インスタンスは固有のSIDも持つべきであり、これは、 サーバーは互いに独立で、分離されていることを意味する。
複数サーバーホスティングのユーザーはそれほど特異ではなく、プロセス管理と起動時それぞれの
場面において、注意深い設定を要求する。注意深く設定しなければならない、smb.conf
パラメーターは以下を含む:
private dir, pid directory,lock directory, interfaces, bind interfaces only, netbios name, workgroup, socket address。
複数のSambaサーバーを作成する事を選択した人は、Sambaソースコードを読解でき、必要に応じて それを変更出来る能力を持つべきである。このモードの配置は、この文書の範囲を超えていると 考えられる。しかし、もしも誰かがより包括的な文書を寄贈してくれるのであれば、喜んでそれを レビューし、もしもそれが適切であれば、この章のこの節を拡張するだろう。そのような文書が 有効になるまで、単一ホスト上での複数Sambaサーバーのホスティングは、Sambaチームによって、 Samba-3ではサポートされないとみなされる。
Sambaは、固有の設定を持つ、複数の仮想サーバーをホスティングできる能力がある。
これは、すべてのホスティングされる、個別設定に共通なsmb.conf
ファイルの設定で達成
される。各(仮想)サーバーの個別設定は、固有のnetbios aliasで
ホスティングされ、おのおのは、固有の異なった[global]セクションを
持つ。各サーバーはサービスとメタサービスのために固有のセクションを持っても良い。
複数の仮想サーバーをホスティングするとき、おのおのには個別設定が出来、おのおのは 異なったワークグループにいる。プライマリサーバーのみ、ドメインメンバーかドメインコントローラーに なれる。個別設定は、動作しているsecurityモードと、使っている netbios aliasesとそれに対して定義された workgroupの組み合わせによって定義される。
この設定スタイルは、NetBIOS名を使うか、NetBIOS名なしのTCPサービスのSMBを使う事が出来る。
もしもNetBIOSモード(最も一般的な方法)で動かす場合、パラメーター
smb ports = 139はプライマリのsmb.conf
ファイル中に
指定すべきである。それを間違うと、SambaはTCPポート445で動作することになり、
最も良い場合で問題のある動作、最悪の場合は、プライマリのsmb.conf
ファイルで指定された
機能を得ることができるのみである。TCPポート139のみを使うNetBIOS over TCP/IPの使用は、
%L
マクロの使用が完全に有効になる事を意味する。もしも
smb ports = 139が指定されていない場合(既定値では
445 139
)か、もしもこのパラメーターの値が
139 445
の時は、%L
は無効である。
各サーバーの個別設定で、ポート445を使う(NetBIOSなしのSMBポート)複数のサーバーを
ホスティングするのは可能で、この場合、(IPアドレスによって)分離されたサーバーを識別する
ために、%i
が使える。おのおのは固有のsecurity
モードを持つ。仮想サーバーを作成するために、interfacesと
bind interfaces onlyをnetbios nameに
追加する必要があるかもしれない。この方法は、TCPポート139のみを使うNetBIOS名を使うよりも
より複雑であると考えられる。
スタンドアロンでユーザーモードのセキュリティで動くSambaと置き換え対象の、 読み取り専用Windows 95ファイルサーバーからなる例題環境を考えてみよう。新しいPCでWindows 95 マシンを置き換える代わりに、Sambaサーバー上でホスティングされる読み取り専用匿名ファイル サーバーとしてこのサーバーを追加することが可能である。以下はそれに必要ないくつかのパラメーター である:
Sambaサーバーの名前はELASTIC
で、そのワークグループ名はROBINSNEST
である。
CDROMサーバーの名前はCDSERVER
で、そのワークグループ名はARTSDEPT
である。出来うる実装は以下の通り:
マスターサーバーに対するsmb.conf
ファイルはElasticのsmb.confファイルである。
このファイルは/etc/samba
中に置かれる。nmbd と smbd デーモンのみが
必要である。サーバーを起動すると、Windowsのネットワークコンピュータ中の、ワークグループ
ROBINSNEST
配下にELASTIC
が現れる。もしも、このサーバーに
アクセスするWindowsクライアントがまたワークグループROBINSNEST
中にいて、
より信頼性の高いブラウジングを行わさせるのに、これは便利である。
Example 34.1. Elasticのsmb.confファイル
CDROMサーバーの設定ファイルはCDROMサーバーのsmb-cdserver.confファイル
である。このファイルはsmb-cdserver.conf
という名前で、
/etc/samba
ディレクトリに置かれる。ワークグループ
ARTSDEPT
中にいるマシンはサーバーを自由にブラウズできる。
2つのサーバーは異なったりソースを持ち、分離されたワークグループ内にいる。サーバー
ELASTIC
は、そのホストサーバー上に適切なアカウントを持つユーザーから
のみアクセスできる。すべてのユーザーは、/export/cddata
ディレクトリ中に格納されるCDROMデータにアクセスできる。ファイルシステムのアクセス許可は、
その他
ユーザーがディレクトリとその内容に対して読み取り専用アクセスを
設定すべきである。ファイルはrootが所有できる(nobodyアカウント以外の任意のユーザーでも)。
この例では、要求されていることは、MIDEARTH
というドメインに対する
プライマリドメインコントローラーに対するものである。PDCはMERLIN
である。その他のマシンとしてSAURON
が必要とされている。各マシンは
それぞれ固有の共有のみ持つ。両マシンは同じドメイン/ワークグループに属している。
マスターのsmb.conf
ファイルはマスターのsmb.conf ファイルのグローバルセクション
である。各サーバーの共有情報を指定する2つのファイルは、
smb-merlin.confファイルの共有セクションと
smb-sauron.confファイルの共有セクションである。3つの
ファイルはすべて/etc/samba
ディレクトリに置かれる。
Example 34.3. マスターのsmb.conf ファイルのグローバルセクション
Example 34.4. smb-merlin.confファイルの共有セクション
Table of Contents
この章では、3.xシリーズのリリースの間に行われた変更の詳細な記録を提供する。この時点で、 このシリーズはGNU GPLバージョン2でライセンスされる3.0.xとGNU GPLバージョン3でライセンス される Samba 3.2.xシリーズがある。
Sambaは常時発展しているソフトウェアで、リリース間で明確な違いがある時もある。それらの 変更点のいくつかは、公式のMicrosoftパッチとアップデートによるセキュリティか機能の更新の 結果、Microsoft Windows ネットワーククライアントによって使われるプロトコルの変更の結果に よってもたらされる。特に、Sambaそれ自身の内部操作に影響するものについては、Sambaは そのような変更に追従しなければならない。
使用しているSambaのバージョンに、明確に言及している、以下のどのような節をも参照して ほしい。一般的に、新しいリリースに適用されるすべての変更は、それ以降のリリースにも 適用される。例えば、Samba3.0.23における変更は、3.0.25を含むそのあとすべての新しい リリースに適用される。Samba 3.2.xは3.2.0固有の変更が適用される前に、Samba 3.0.25から オリジナルが分割された。3.0.xシリーズの機能が特に無効にされていないのならば、 3.2.xシリーズの動作は、それ以前のパターンに沿うと推測できる。
Samba-3.0.25の既定値の動作は、おおよそSamba-2.2.xと同じであるべきである。smb.conf
ファイル中に新しいパラメーターpassdb backendが定義されていない
場合の既定値の動作は、encrypt passwords = Yesと
smbpasswd
データベースを使う、Samba-2.2.xの既定値の動作と同じに
なる。
なぜ、動作がおおよそSamba-2.2.xと同じであるべきであると言うのか? なぜならば、Samba-3.0.25は、結果として異なったプロトコルコードパスを取るかもしれない ネイティブなユニコードをサポートするような、新しいプロトコルを使うことが出来るからである。 そのような環境における新しい動作は、古いものとは正確に同じではない。うれしいことに、 ドメインとマシンSIDはアップグレードにおいて保存される。
もしも、Samba-2.2.xがLDAPを使っていて、LDAPデータベースを更新する時間がないならば、
smb.conf
ファイル中でpassdb backend = ldapsam_compat
を指定する。その他の点に関しては、動作は多かれ少なかれ同じであるべきである。
その後、Samba-3互換のLDAPバックエンドに切り替える時間があるとき、pdbedit
を使って古いLDAPデータベースを新しいものに移行することは可能である。
The pdbeditコマンドを参照のこと。
新機能のうち代表的なものは以下の通り:
Active Directoryのサポート。このリリースはメンバーサーバーとしてADS realmに参加でき、 LDAP/Kerberosを使ってユーザーの認証が出来る。
ユニコードのサポート。Sambaはネットワーク上でUnicodeを使えるようになり、 マルチバイトとユニコード文字セットを扱うための、よりよい基盤を内部にもつ ようになった。
新しい認証システム。内部の認証システムはほとんど書き換えられた。変更の多くは 内部的なものであるが、新しい認証システムはとても自由に設定できる。
新しい、ファイル名の短縮システム。ファイル名短縮システムは完全に書き換えられた。 内部データベースは、恒久的に短縮マップを格納する。
新しい“net”コマンド。新しい“net”コマンドが追加された。 Windows中の“net”コマンドと幾分似ている。結局、たくさんある他の ユーティリティ(たとえばsmbpasswd)を“net”中のサブコマンドで 置き換えることを計画している。
Sambaはネットワーク上でNT形式のstatus32コードで通信できるようになった。 これはかなりエラーハンドリングを改善する。
よりよいWindows 200x/XP印刷サポート。Active Directory中にプリンター属性を 公開することを含む。
SIDからUID/GIDマッピングをLDAPディレクトリに格納する事による、 分散Winbindアーキテクチャの新規サポート。
Samba文書構造の大規模な更新。
既定値のWindows 2003セキュリティ設定との互換を取るために、サーバーと クライアントにおけるSMB署名の完全なサポート。
さらに多くの改良がある!
この節には、Samba-2.2.xシリーズからSamba-3.0.25を含むまでのsmb.conf
の変更の
簡単な一覧がある。
新規、あるいは変更されたパラメーターについての完全な説明は、smb.conf(5)のマニュアル ページを参照のこと。
Sambaのアップデートあるいはアップグレードをするときはいつでも、Sambaの配布セット の一部である、WHATSNEW.txtというファイルを読むことを強く推奨する。 このファイルは、Sambaのwebサイトの、 右側のカラム、Current Stable Releaseの下で、Release Notesを クリックして入手してもよい。
アルファベット順で、以下はSamba-2.2.xから3.0.35で削除されたパラメーターの一覧である。
admin log
alternate permissions
character set
client codepage
code page directory
coding system
domain admin group
domain guest group
enable rid algorithm
enable svcctl
force unknown acl user
hosts equiv
ldap filter
min password length
nt smb support
post script
printer admin
printer driver
printer driver file
printer driver location
read size
source environment
status
strip dot
total print jobs
unicode
use rhosts
valid chars
vfs options
winbind enable local accounts
winbind max idle children
wins partners
以下の新しいパラメーターは、Samba 3.0.25までにリリースされたものである(機能毎にグルーピング:)
リモート管理
abort shutdown script
shutdown script
ユーザーとグループアカウント管理
add group script
add machine script
add user to group script
algorithmic rid base
delete group script
delete user from group script
passdb backend
rename user script
set primary group script
username map script
認証
auth methods
ldap password sync
passdb expand explicit
realm
プロトコルオプション
add port command
afs token lifetime
client lanman auth
client NTLMv2 auth
client schannel
client signing
client use spnego
defer sharing violations
disable netbios
dmapi support
enable privileges
use kerberos keytab
log nt token command
ntlm auth
paranoid server security
sendfile
server schannel
server signing
smb ports
svcctl list
use spnego
ファイルサービス
allocation roundup size
acl check permissions
acl group control
acl map full control
aio read size
aio write size
dfree cache time
dfree command
ea support
enable asu support
fam change notify
force unknown acl user
get quota command
hide special files
hide unwriteable files
inherit owner
hostname lookups
kernel change notify
mangle prefix
map acl inherit
map read only
max stat cache size
msdfs proxy
open files database hash size
set quota command
store dos attributes
use sendfile
usershare allow guests
usershare max shares
usershare owner only
usershare path
usershare prefix allow list
usershare prefix deny list
usershare template share
vfs objects
印刷
cups options
cups server
force printername
iprint server
max reported print jobs
printcap cache time
ユニコードと文字セット
display charset
dos charset
UNIX charset
SIDからUID/GIDへのマッピング
idmap backend
idmap gid
idmap uid
username map script
winbind nss info
winbind offline logon
winbind refresh tickets
winbind trusted domains only
template primary group
LDAP
ldap delete dn
ldap group suffix
ldap idmap suffix
ldap machine suffix
ldap passwd sync
ldap replication sleep
ldap timeout
ldap user suffix
一般的な設定
eventlog list
preload modules
reset on zero vc
privatedir
acl group control (新しい既定値は No, 廃止されるパラメーター)
change notify timeout (スコープが変更)
dos filemode (既定値で無効に)
dos filetimes (既定値で有効に)
enable asu support (既定値で無効に)
enable privileges (既定値で有効に)
encrypt passwords (既定値で有効に)
host msdfs (既定値で有効に)
mangling method (既定値でhash2を設定)
map to guest
only user (廃止)
passwd chat
passwd program
password server
restrict anonymous (整数値)
security (新しくadsが追加)
strict locking (既定値でautoに)
winbind cache time (5分に増加)
winbind enum groups (既定値で無効に)
winbind enum users (既定値で無効に)
winbind nested groups (既定値で有効に)
winbind uid (idmap uidのために廃止に)
winbind gid (idmap gidのために廃止に)
winbindd nss info
write cache (廃止)
Samba-2.2.xシリーズからの主要な動作の変更点は、この節に記述してある。現在の
Sambaリリースのサポート期間中に行われた変更に関連する詳細情報を得るためには、
各Sambaリリースに同梱されるWHATSNEW.txt
を参照してほしい。
インストール、第一章, 第一章に、Samba-3データファイルに関連する、 その配置とサーバー移行、アップデートとアップグレードにおいて保持しなければ ならない情報があるので、参照してほしい。
Samba-3にアップグレードする前に、存在している${lock directory}/*tdbをバックアップ する事を忘れないでほしい。もしも必要ならば、Sambaはオープンされているように データベースをアップグレードする。Samba-3から2.2へのダウングレードか、 最新版のSamba-3より前のバージョンへの変更は、サポートされない手順である。
古いSamba-2.2.xのtdbファイルは次のテーブル で説明されている。
Table 35.1. Samba-2.2.xのTDBファイルの説明
名前 | 説明 | バックアップ必要? |
---|---|---|
account_policy | ユーザーポリシーの設定 | yes |
brlock | バイトレンジファイルロック情報 | no |
connections | クライアント接続情報 | no |
locking | 一時ファイルロックデータ | no |
messages | smbdによって生成されたメッセージの一時的な記憶場所 | no |
ntdrivers | プリンター毎のドライバー情報を格納 | yes |
ntforms | プリンター毎のフォーム情報を格納 | yes |
ntprinters | プリンター毎のdevmode設定情報を格納 | yes |
printing/*.tdb | 印刷サービス毎に作成されたlpqコマンドからのキャッシュされた出力 | no |
registry | 読み取り専用のSambaレジストリスケルトンで、winreg RPC経由で種々の データベーステーブルをエクスポートする機能を提供する。 | no |
sessionid | その他のセッション情報のための一時的なキャッシュ。 | no |
share_info | 共有のACL設定。 | yes |
unexpected | どのプロセスもリッスンしていないパケットの受信用。 | no |
winbindd_cache | NT4かADSドメインから受信した識別情報のキャッシュ。 | yes |
winbindd_idmap | SIDからUNIXのUID/GIDへの新しいIDマップテーブル。 | yes |
以下の問題はSamba-2.2とSamba-3の間で、特定のインストール状態におけるSambaの動作の 変更点として知られている。
操作がWindowsドメインのメンバーの場合、Samba-2.2は、もしもUIDがgetpwnam() 呼び出し経由で得られなかった場合、“guest account”に、リモート DCによって認証された任意のユーザーをマップする。Samba-3は、 “NT_STATUS_LOGON_FAILURE”というエラーメッセージで接続を 拒否する。Samba-2.2の動作を再度確立するための現時点での回避策はない。
Samba-2.2で制御されたドメインにマシンを追加するとき、 “add user script”はマシン信頼アカウントのUNIX識別子を 作成するのに使われる。Samba-3では新しい “add machine script”という、この目的のために指定しなければ ならないスクリプトを導入している。Samba-3は、 “add machine script”がない場合に、 “add user script”を使うように切り替える事はしない。
Samba-3に移動するときにSamba管理者が知っておくべきいくつかの新しい変更が ある。
暗号化されたパスワードは、Windowsクライアントをそのまま使える事との
相互運用性を向上させるために、既定値で有効になった。これは、(a)
Sambaアカウントは各ユーザー毎に作成する必要があるか、(b)
“encrypt passwords = no”を明示的に smb.conf
中で定義する
必要があるということである。
ネイティブなWindows Kerberos 5とLDAPプロトコルを使う、Active Directory ドメインとの統合のための、新しいsecurity = ads オプションの包含。
Samba-3は、認証方法を複数設定できる機能(auth methods)
と、アカウント格納バックエンドを複数設定できる機能(訳注:現在は無効)
(passdb backend)がある。詳細は、smb.conf
マニュアル
ページとアカウント情報データベースを参照して
ほしい。両方のパラメーターが妥当な既定値を仮定している間、Sambaの動作を実際に
どの値が正しくさせているかを理解する必要があることはありえる。
smbpasswd
の特定の機能は、新しいsmbpasswd
ユーティリティ、net
ツールと新しいpdbedit
ユーティリティの間で分割された。詳細は、それぞれのマニュアルページを参照のこと。
この節では、Samba/LDAP統合に影響する新しい機能の概要を説明する。
新しいオブジェクトクラス(sambaSamAccount)が古いsambaAccountを置き換える ために導入された。この変更は、他のベンダからの属性を破壊するのを防ぐための、 属性の変更を支援する。LDIFファイルを新しいスキーマに変更するための変換 スクリプトがexamples/LDAP/convertSambaAccountにある。
$
ldapsearch .... -LLL -b "ou=people,dc=..." > old.ldif$
convertSambaAccount --sid <DOM SID> --input old.ldif --output new.ldif
<DOM SID>は以下を、Samba PDC上で、rootで動かすことで入手できる。
$
net getlocalsid <DOMAINNAME>
Samba-2.x下では、ドメインSIDは以下を実行することで得られる:
$
smbpasswd -S <DOMAINNAME>
古いsambaAccount
スキーマは、
ldapsam_compat
passdb バックエンドを指定することで
引き続き使っても良い。しかし、sambaAccountと関連する属性はスキーマ
ファイルの歴史的セクションに移動済みで、もしも必要な場合、使う前に
コメントアウトしなければならない。sambaAccount
に対するSamba-2.2オブジェクトクラスの定義は、Samba-3の
samba.schema
ファイル中では変更されていない。
他の新しいオブジェクトクラスとそれが使うものは以下の通り:
sambaDomain
必要に応じて
ユーザーとグループのRIDを割り当てるために使われるドメイン情報。
もしもidmap UID/GIDの範囲が設定され、“ldapsam”
passdbバックエンドが選択された場合、属性は
“ldap suffix”ディレクトリエントリ中に、
自動的に追加される。
sambaGroupMapping は、posixGroupとWindowsのグループ/SID との間で関連づけを行うためのオブジェクト。これらのエントリは “ldap group suffix”中に格納され、 “net groupmap”コマンドによって管理される。
sambaUNIXIdPool
“ldap idmap suffix”エントリ中に自動的に作成され、
次に有効な“idmap UID”と“idmap GID”
を格納している。
sambaIdmapEntry
SIDとUNIXのUID/GID間でのマッピングを格納するオブジェクト。
これらのオブジェクトは必要に応じてidmap ldapモジュールにより
作成される。
以下の新しいsmb.conf
パラメーターは、
passdb backend = ldapsam://...
が指定された時に
特定のLDAPクエリを指示するのを支援するために追加された。
ldap suffix ユーザーとコンピュータアカウントを検索するのに使用。
ldap user suffix ユーザーアカウントを格納するのに使用。
ldap machine suffix マシン信頼アカウントを格納するのに使用。
ldap group suffix posixGroup/sambaGroupMappingエントリの位置。
ldap idmap suffix sambaIdmapEntryオブジェクトの位置。
もしも、ldap suffix
が定義されていた場合、これは残りの
subsuffixパラメーターに追加される。この場合、smb.conf
中のサフィックスの
記述順序は重要である。常時、他のものよりも前に、
ldap suffix
を記述すること。
Sambaのsmb.conf
解析の制限により、引用符でドメイン名を囲ってはいけない。
Samba-3はidmapサブシステムにもLDAPバックエンドをサポートしている。以下の オプションは、Sambaにidmapテーブルを、ディレクトリサーバー onteroseの ou=Idmap,dc=quenya,dc=org部分に格納する事を指示する。
[global] |
... |
idmap backend = ldap:ldap://onterose/ |
ldap idmap suffix = ou=Idmap |
idmap uid = 40000-50000 |
idmap gid = 40000-50000 |
この設定では、UID/GID名前空間を複数のサーバー上で共有するWinbindの利用が 出来るようになり、Samba-2.2で存在していた、NFSとの相互運用の問題を 解決する。
Table of Contents
これは、NT4ドメイン制御からSamba-3ベースのドメイン制御に移行する事を手助けするための、 大まかなガイドである。
ITの世界では、しばしば、すべての問題は、貧弱な計画のために発生すると言われている。 この言葉の結果として、予期され、計画される問題はすべてではない。さらに言うと、 計画が良いと、ほとんどの、致命的なタイプの状況を予想できると言うことである。 In the IT world there is often a saying that all problems are encountered because of poor planning. The corollary to this saying is that not all problems can be anticipated and planned for. Then again, good planning will anticipate most show-stopper-type situations.
Microsoft Windows NT4ドメイン制御からSamba-3ドメイン制御環境への移行を考えている場合、 詳細な移行プランを作成すべきである。そこで、ここでは、移行を進めるために手助けとなる、 いくつかの点について説明する。
多くの組織における重要な目的は、可能な限り副作用がないように、Microsoft Windows NT4 からSamba-3ドメイン制御に移行を行うことである。移行手順において体験する挑戦の1つは、 新しい環境でも状態がそのまま残っているという、説得力のある状態の提供であろう。 オープンソース技術を導入する人は、最初にトラブルの徴候があったときに、Microsoftベースの プラットフォームソリューションに戻せ、という圧力を体験するだろう。
Samba-3が制御しているネットワークに移行を試みる前に、可能な限り、周りすべてから、 変更に対する、承認を得る努力を行うようにする。なぜ組織において 変更が重要であるかを正確に理解しておくこと。変更を行う動機付けの例としては以下がある:
ネットワーク管理の容易性向上。
ユーザーレベルでのよりすぐれた機能の提供。
ネットワーク運用コストの低減。
MicrosoftによるNT4サポート終了によって引き起こされるexposureの低減。
Avoid MS License 6 implications.
組織がMicrosoftに依存する事の低減。
Samba-3はMicrosoft Windows NT4ではないことを、誰でもが知っておくようにすること。 Samba-3はMicrosoft Windows NT4とも、それに対して利点を提供する事とも異なる、代替 ソリューションを提供する。Samba-3は、Microsoft NT4からMicrosoft Windows 2000と その後継(Active Directoryサービスを使う/使わないのどちらでも)への移行における、 本質的な価値として紹介している多くの機能を持っていないことを認識すること。
Samba-3が提供できていないはどのようなものがあるだろうか?
Active Directoryサーバー
グループポリシーオブジェクト(Active Directory中の)。
マシンポリシーオブジェクト。
Active Directory中のログオンスクリプト
Active Directory中のソフトウェアアプリケーションとアクセス制御。
Samba-3の機能で提供していないものと、使用しているサイトでとても大きな関心があるかも しれないものは以下の通り:
より少ない所有コスト。
Global availability of support with no strings attached.
UNIX/Linuxシステム単位で1つ以上のSMB/CIFSサーバーを動作できる)。
その場その場でのログオンスクリプトの作成。
その場その場でのポリシーファイルの作成。
より優れた安定性、信頼性、パフォーマンスと可用性。
SSH接続経由よる操作性。
バックエンド認証技術を自由に選べる(tdbsam,ldapsam)。
完全なシングルサインオン技術の実装機能。
絶対的に小さい広域ネットワークのバンド幅を要求するための分散認証技術機能。
Microsoft Windows NT4からSamba-3へのネットワーク移行の前に、すべての必要な要素を考慮する。 変更についてユーザーを教育し、そうすることでユーザーに受け入れられるようになり、必要な仕事の 障害にならないようにすべきである。以下の節では、移行を成功させるための要素について説明 している。
Samba-3はドメインコントローラー、バックアップドメインコントローラー(おそらく、最も 広くセカンダリコントローラーと呼ばれる)、ドメインメンバー、あるいはスタンドアロンサーバーとして 設定できる。Windowsネットワークセキュリティドメインコンテキストは、実装の前に、 sized(?)と、よく調査を行うべきである。バックアップドメインコントローラー(BDC)と同様、 プライマリドメインコントローラー(PDC)を配置するため、特別な注意を払う必要がある。 Samba-3がMicrosoftの技術とは違う1つの方法は、もしもLDAP認証バックエンドを使うことを 選択した場合、同じデータベースをいくつかの異なったドメインで使うことが出来るという ことである。複雑な組織において、それは、同時に多数のドメインをサポートできる、 分散可能な(1つのマスターサーバーと複数のスレーブサーバー)単一のLDAPデータベースにできる。 Samba-3 can be configured as a domain controller, a backup domain controller (probably best called a secondary controller), a domain member, or a standalone server. The Windows network security domain context should be sized and scoped before implementation. Particular attention needs to be paid to the location of the Primary Domain Controller (PDC) as well as backup controllers (BDCs). One way in which Samba-3 differs from Microsoft technology is that if one chooses to use an LDAP authentication backend, then the same database can be used by several different domains. In a complex organization, there can be a single LDAP database, which itself can be distributed (have a master server and multiple slave servers) that can simultaneously serve multiple domains.
デザインの観点から、1台のサーバーあたりのユーザー数はドメインあたりのサーバーの数と同様、 サーバーの能力とネットワークのバンド幅を考慮に入れて、スケーリングすべきである。
物理的なネットワークセグメントはいくつかのドメインを収容しているかもしれない。おのおのは、 複数のネットワークセグメントにまたがっているかもしれない。ドメインがルーテイングされた セグメントにまたがっている場合、ネットワークの設計とレイアウトのパフォーマンス評価を テストし考慮する。複数のルーティングされたネットワークセグメントをサポートするように 設計された、中央に位置するドメインコントローラーは、パフォーマンスが悪いという問題を 引き起こすかもしれない。リモートセグメントとPDC間のレスポンスタイム(pingのタイミング)を 調べること。もしもそれが長い(100msよりも大きい)場合、ローカルでの認証を提供する ために、リモートセグメント上にBDCを配置し、制御サーバーにアクセスする。
足を付けずには破ることの出来ない、効果的なネットワーク設計のための基本原則がある。 最も重要なルールは:よく制御されたネットワークおのおのにおいて、単純さを確保すること。 基盤のすべての部分は、管理可能にしなければならない。それをより複雑にすると、 システムをセキュアに保つことと機能を確保することの要求は増大するだろう。
どのようにデータを共有しなければならないかという性質について、心にとめておくこと。 物理ディスクスペースレイアウトは注意深く考えられるべきである。いくつかのデータは バックアップが必要である。ディスクレイアウトを単純にすると、バックアップの必要性を 記録するのはより容易になるだろう。どのメディアが必要を満たすかについて見極めること。 テープ、CD-ROMあるいはDVD-ROMや他のオフラインストレージシステムを考慮する。最小限の メンテナンスを計画し、実現の用意をする。設計の中に危険な点を残さないこと。とりわけ、 バックアップすることを忘れてはならない。バックアップし、テストし、すべてのバックアップを 検証する。ディザスタリカバリプランを作成し、それが動くかを検証する。
データアクセス制御の必要性を付与するために、ユーザーはグループ化されるべきである。 ファイルとディレクトリアクセスは、グループパーミッション経由で最もよく制御でき、 グループ制御のディレクトリ上に“スティッキービット”を使うと、Sambaの 共有ユーザーからのファイルアクセス時の不満を十分に防止するかもしれない。
未経験のネットワーク管理者は、しばしば、ファイル、ディレクトリ、共有に対して、共有内の 定義と同じようにアクセス制御を設定するための、手が込んだ技術を適用しようとする。 設計と実装は単純にすること、そして、広範囲に設計を文書化すること。他の誰かが作成した 文書を監査するようにすること。後継者が理解できないような、複雑な文書を作らないこと。 覚えておいてほしいのは、複雑な設計と、実装を使うジョブのセキュリティは、新参の管理者が 結び目のほぐし方を学ぶように、利用者に対して、運用障害と運用停止をもたらすかも しれない。アクセス制御は簡単かつ効果的にして、obtuse complexityによって中断されることの 無いようにする。 Inexperienced network administrators often attempt elaborate techniques to set access controls on files, directories, shares, as well as in share definitions. Keep your design and implementation simple and document your design extensively. Have others audit your documentation. Do not create a complex mess that your successor will not understand. Remember, job security through complex design and implementation may cause loss of operations and downtime to users as the new administrator learns to untangle your knots. Keep access controls simple and effective, and make sure that users will never be interrupted by obtuse complexity.
ログオンスクリプトは、すべてのユーザーが必要に応じて共有とプリンターへの接続を得る事を 保証する事を手助けするものである。
ログオンスクリプトは、動的に作成でき、動作させるすべてのコマンドは、そのユーザーが持つ
権限と権利が指定される。優先する制御の設定は、グループメンバーシップを使って設定
すべきであり、グループ情報は、カスタムログオンスクリプトを作成するために使われ、
それは、NETLOGON
共有に対する
root preexecパラメーターを使う。
いくつかのサイトでは、制御されたユーザー環境を確立するために、kixstart
のようなツールを使っている。この場合、ログオンスクリプトプロセス制御のために、Google検索を
行ってもよい。実際、ログインスクリプト経由で、ユーザーが介入することなしに、
プリンターを追加する方法について記述しているMicrosoft Knowledge Baseの記事KB189105の使用法
を調査してもよい。
おおよその移行プロセスは以下の通りである。
Procedure 36.1. アカウント移行プロセス
NT4 サーバーマネージャを使い、Sambaサーバーを古いNT4ドメイン中でBDCに設定する。 Samba must not be running.
pdbedit -L
注意: ユーザーは移行できただろうか?
次に、各UNIXグループをNTグループに割り当てる:
initGroups.sh
として下記のテキストをコピーし、スクリプトに
しておくと便利である。)
#!/bin/bash #### Keep this as a shell script for future re-use # First assign well known domain global groups net groupmap add ntgroup="Domain Admins" unixgroup=root rid=512 type=d net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=d net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d # Now for our added domain global groups net groupmap add ntgroup="Designers" unixgroup=designers type=d net groupmap add ntgroup="Engineers" unixgroup=engineers type=d net groupmap add ntgroup="QA Team" unixgroup=qateam type=d
net groupmap list
すべてのグループが認識されたかを確認する。
すべてのプロファイルの移行と、すべてのポリシファイルの移行。
Microsoft Windows NT4ドメイン制御からSambaベースのソリューションへの移行を行いたい サイトは、一般的に3つの基本的なカテゴリに適合する。 以下のテーブルは、その例を表示する。
Table 36.1. 3つの主要なサイトのタイプ
ユーザー数 | 説明 |
---|---|
< 50 | 特段の手間暇を掛けずに単純な移行をしたい。 |
50 - 250 | 新しい機能を追加したい。いくつかの、組織内の複雑制を管理することが出来る。 |
> 250 | ソリューション/実装は規模に対応しなければならない。 複雑な要求がある。組織間の調整。ほとんどの領域での専門的な知識。 |
Microsoft Windows NT4からSamba-3へ移行したいサイトには、3つの基本的な選択肢がある。
単純な移行 (丸ごと取り替え)。
アップグレードする移行(統合の一種でありえる)。
完全な再設計 (完全に新しいソリューション)。
終了間際の問題を最小にするには:
十分な時間の確保。
パニックを防ぐ。
すべての仮定のテスト。
ワークステーションの展開を含む、完全に提供されるプログラムのテスト。
以下のテーブルは、与えられた、予想される 移行のタイプの移行の選択肢を一覧表示する。
Table 36.2. 移行方式による相違点の詳細
単純移行 | アップグレード | 再設計 |
---|---|---|
最低限のOS固有機能の使用 | NT4の機能を新しいホストOSの機能に変更 | NT4の機能を改善し、管理能力を強化 |
NT4からSamba-3にすべてのアカウントを移行 | コピーと改善 | 認証システム(データベースの配置とアクセス) |
最低限の操作上の変更 | 漸進的な改良 | デスクトップ管理手法 |
最小限の移行時間 | ユーザーへのインパクトを最小化 | デスクトップ/ユーザーの制御を改善 |
運用停止を伴う移行作業 | 最大限の機能を利用 | 管理性、拡張性、保全性、可用性に対する必要性の識別 |
Samba-3の統合は、ユーザーが有効な時に移行し、次に、制御を変更(スワップアウト) Integrate Samba-3, then migrate while users are active, then change of control (swap out) | 管理操作が少ないことを有効に利用 |
Samba-3は外部の認証バックエンドを使える:
Winbind (他のSambaかNT4/200xサーバー)。
外部サーバーはActive DirectoryかNT4ドメインを使える。
ホームディレクトリの自動作成を行うために、pam_mkhomedir.soが使える。
Samba-3はローカル認証バックエンドとして: smbpasswd
,
tdbsam
, ldapsam
が使える。
Sambaは以下の場所でアクセス制御を設定できる:
共有それ自身では共有ACLを使う。
ファイルシステム上ではファイルとディレクトリ上でUNIXのパーミッションを使う。
注意:POLIX ACLは、ファイルシステム中でも有効に出来る。
Sambaの共有パラメーターも使えるが苦肉の策以外、推奨しない。
レジストリの変更時には、十分に用心すること;正しいツールを使い、恒久的に
変更点が保存される、NT4形式のNTConfig.POL
ファイルを
経由して変更が行われることに注意。
グループポリシーエディターを使用(NT4)
入れ墨効果(tattoo effect)に注意。
プラットフォーム固有の場合では、ローカルから、ローミングプロファイル変更するために、
プラットフォームのツールを使う。SIDを変更するために新しいプロファイルツールが
使える(NTUser.DAT
)。
それがどのように動くかは分かっている。
ユーザーとグループマッピングコードは新しくなった。Samba-2.2.xからSamba-3に 移行することになれているネットワーク管理者は、多くの問題を体験した。 新しいパスワードバックエンドの動作と、新しいグループマッピング機能について 記述している章を注意深く学習すること。
username map
機能が必要になるかもしれない。
net groupmap
でNT4グループをUNIXグループにつなぐ。
ユーザー設定を設定/変更するためにpdbedit
を使う。
LDAPバックエンドに移行するとき、初期LDAPデータベースをLDIFにダンプ、 編集し、次にLDAPに再ロードするのは容易である。
すべてのOSはそれ固有の習慣がある。設計者の体験と、予期されない副作用があるかもしれない 事をベースにする技術的な議論の結果がある。Windowsネットワーク管理者が引っかかる制限には 以下のものがある:
ユーザーの追加/削除: OSによる名前のサイズ制限に注意 (Linuxは8文字まで, NT4は254文字まで)。
マシンの追加/削除: ドメインメンバーのみに適用される (注意:マシン名は16文字までに制限される)。
NT4グループからUNIXグループへ接続するためにnet groupmap
を使用。
グループの追加/削除:OSによるサイズと特性の制限に注意。
Linuxは16文字まで、空白不可、大文字不可(groupadd
)。
ドメイン制御(NT4形式)プロファイル、ポリシー、アクセス制御、セキュリティ
Samba: net, rpcclient, smbpasswd, pdbedit, profiles
Windows: NT4 ドメインユーザーマネージャ, サーバーマネージャ(NEXUS)
Table of Contents
SWATの有用性に関連しては、数多くの様々な意見がある。完璧な設定ツールを作ろうとする
試みはとても大変な事なのにもかかわらず、個人的な興味の対象として存在している。
SWATはSambaをWebベースで設定するためのツールである。これは、Sambaを簡単に設定する
ための手助けとなりえるウィザードであり、場面に応じて各smb.conf
パラメーターの
ヘルプをWebベースで表示し、現在の接続状況をモニターリングする機能を提供し、ネットワーク
全体の、Microsoft Windowsネットワークパスワード管理ができる。
SWATはSambaシステムの一部である。基本となるプログラム名はswat
であり、
これはinetdのようなスーパーデーモンによって起動される。詳細は
説明の節を参照のこと。
SWATは特定のバージョンのSambaによってサポートされる、パラメーターを使うために、
Sambaコンポーネント全体を使う。Samba外部のツールとユーティリティとは異なり、
SWATは常時Sambaパラメーターが変更されることに追従している。SWATは各設定パラメーターに
対して、場面に応じて、マニュアル
ページのエントリから、直接
ヘルプを提供する。
ネットワーク管理者の何人かは、設定ファイル中にシステムの説明を書き込むことは良いアイデア
だと思っている人もいるが、そういう人にとって、SWATは常にひどいツールである。SWATは、
何らかの中間的な形式でも、設定ファイルに格納しない。というよりは、パラメーターの設定のみを
書き込む。SWATがsmb.conf
ファイルをディスクに書き込むときには、既定値の設定以外の
パラメーターのみを書き込む。結果、パラメーターと同じように、すべてのコメントは保持されず、
smb.conf
ファイル中から無くなってしまう。おまけに、パラメーターは内部での順番に
書き戻される。
この節では、どのようにSWATが動くかせるかという仕掛けの背景にある、秘密の闇を明らかにする 事と、どのようにセキュアに出来るかということと、どのように国際化のサポートを解決するか という事を説明する。
SWAT操作のためにホストシステムを設定する試みの前にやるべきである、ごく最初のステップは、 それがインストールされているかを調べることである。これは、ある人にとっては取るに足らない ことに見えるかもしれないが、いくつかのLinuxディストリビューションでは、 ディストリビューションメディア上で、SWATを含む、インストール可能なバイナリパッケージを 提供しているにもかかわらず、SWATを既定値ではインストールしていない。
SWATがインストールされていることを確認したら、すべてのサポートしているテキストとWeb
ファイルと同じように、インストールされているバイナリswat
ファイルを
有効化することが必要である。過去、多くのOSディストリビューションが、
swat
バイナリ実行形式ファイルがインストールされているのにも
かかわらず、サポートに必要なファイルを含めることに失敗している。
最後に、SWATが完全にインストールされたと思ったら、使用しているOSプラットフォームで 使われているinetd系スーパーデーモン(inetdかxinetd)用の制御ファイルで、SWATが 有効になっているかを調べてほしい。
SWATがインストールされたかを検証するため、最初に、システム上のswat
バイナリファイルを捜す。それはおそらく以下のディレクトリ配下にあるだろう:
/usr/local/samba/bin 既定値のSambaでの位置 |
/usr/sbin ほとんどのLinuxシステムでの既定値の位置 |
/opt/samba/bin |
実際の位置はOSベンダの選択か、Sambaをコンパイルしてインストールした管理者の決定によって 大きく変わる。
swat
バイナリファイルを見つけるために使う方法にはいろいろある。
以下の方法を使うと便利である。
もしも、swat
が現在のOSサーチパス中にあるならば、それを見つけるのは
簡単である。以下のように、swat
が、どのようなコマンドラインオプションを
持っているかを調べてみればよい:
frodo:~ # swat -? Usage: swat [OPTION...] -a, --disable-authentication Disable authentication (demo mode) Help options: -?, --help Show this help message --usage Display brief usage message Common samba options: -d, --debuglevel=DEBUGLEVEL Set debug level -s, --configfile=CONFIGFILE Use alternative configuration file -l, --log-basename=LOGFILEBASE Basename for log/debug files -V, --version Print version
swat
がサーチパス中に見つかったならば、ファイルがどこに
配置されているかを識別するのは簡単である。これを行う簡単な別解は以下の通り:
frodo:~ # whereis swat swat: /usr/sbin/swat /usr/share/man/man8/swat.8.gz
もしも上記による調査で、swat
バイナリを見つけるのに失敗したら、
他の方法が必要である。以下が使える:
frodo:/ # find / -name swat -print /etc/xinetd.d/swat /usr/sbin/swat /usr/share/samba/swat frodo:/ #
この一覧は、このサーバーにインストールされているinetd系スーパーデーモン
xinetd
の制御ファイルを表示している。SWATバイナリファイルの位置は
/usr/sbin/swat
であり、それがサポートしているファイルはディレクトリ
/usr/share/samba/swat
配下にあることを表示している。
次に、swat
が使うサポートファイルがどこにあるかを調べる。これは
以下のやり方で行う:
frodo:/ # strings /usr/sbin/swat | grep "/swat" /swat/ ... /usr/share/samba/swat frodo:/ #
この一覧の中にある/usr/share/samba/swat/
エントリは、サポートファイルの
位置である。このディレクトリ配下にサポートファイルが存在しているかを調べるべきである。
以下は一覧の例である:
jht@frodo:/> find /usr/share/samba/swat -print /usr/share/samba/swat /usr/share/samba/swat/help /usr/share/samba/swat/lang /usr/share/samba/swat/lang/ja /usr/share/samba/swat/lang/ja/help /usr/share/samba/swat/lang/ja/help/welcome.html /usr/share/samba/swat/lang/ja/images /usr/share/samba/swat/lang/ja/images/home.gif ... /usr/share/samba/swat/lang/ja/include /usr/share/samba/swat/lang/ja/include/header.nocss.html ... /usr/share/samba/swat/lang/tr /usr/share/samba/swat/lang/tr/help /usr/share/samba/swat/lang/tr/help/welcome.html /usr/share/samba/swat/lang/tr/images /usr/share/samba/swat/lang/tr/images/home.gif ... /usr/share/samba/swat/lang/tr/include /usr/share/samba/swat/lang/tr/include/header.html /usr/share/samba/swat/using_samba ... /usr/share/samba/swat/images /usr/share/samba/swat/images/home.gif ... /usr/share/samba/swat/include /usr/share/samba/swat/include/footer.html /usr/share/samba/swat/include/header.html jht@frodo:/>
もしも必要とされるファイルが内ならば、SWATを使う前に、それらを入手してインストールする 必要がある。
SWATはネットワークスーパーデーモン経由で動くようにインストールすべきである。
使用しているUNIX/Linuxシステムが持っているものに依存するので、
inetd
かxinetd
ベースのシステムのどちらかを使う。
ネットワークスーパーデーモンの機能と配置はOSの実装により変わる。制御ファイルは
/etc/inetd.conf
かディレクトリ/etc/[x]inet[d].d
か
同様の位置に置くことが可能である。
# swat is the Samba Web Administration Tool swat stream tcp nowait.400 root /usr/sbin/swat swat
新しい形式でのxintd用制御ファイルは以下の通り:
# default: off # description: SWAT is the Samba Web Admin Tool. Use swat \ # to configure your Samba server. To use SWAT, \ # connect to port 901 with your favorite web browser. service swat { port = 901 socket_type = stream wait = no only_from = localhost user = root server = /usr/sbin/swat log_on_failure += USERID disable = no }
上記の中で、disable
の既定値の設定はyes
である。
これは、SWATが無効になっていることを意味する。SWATを有効にするには、上記のように、
このパラメーターをno
に設定する。
上記の例は両方ともswat
バイナリがディレクトリ
/usr/sbin
に配置されていることを仮定している。上記に補足すると、
SWATは他の制御情報と同じように、自身のヘルプファイルをそこからロードするディレクトリ
アクセス点として使う。多くのLinuxシステムにおけるこのための既定値の位置は、
/usr/share/samba/swat
である。Sambaが使う既定値の位置は、
/usr/local/samba/swat
である。
SWATへアクセスするとログオンを要求される。もしも非rootユーザーでSWATにログオンすると、 パスワード変更機能へのアクセスと同じように、一定の設定範囲にのみアクセスが許可される。 非rootユーザーが見えるボタンは、 、 、 と である。この場合に変更 可能なページは だけである。
rootユーザーでSWATにログオンすると、完全な修正、更新権限を得られる。 表示されるものは、 , , , , , , と である。
多くの人が、Sambaをリモートから安全に管理することが出来るために、どのように SSLを使うSWATを設定するかについて問い合わせしている。以下はMarkus Kriegerの 好意による、そのやりかたである。
SWAT設定の変更点は以下のようになる:
証明書(ertificate)とプライベートキーを生成する。
root#
/usr/bin/openssl req -new -x509 -days 365 -nodes -config \ /usr/share/doc/packages/stunnel/stunnel.cnf \ -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem
[x]inetdからSWATエントリを削除する。
root#
stunnel -p /etc/stunnel/stunnel.pem -d 901 \ -l /usr/local/samba/bin/swat swat
その後、単純に、URL https://myhost:901 を使ってSWATにアクセスし、証明書を受け付け、SSL接続を確立する。
SWATは、使用しているWebブラウザーの言語設定に一致するように、そのメッセージを表示するよう 設定できる。これは、HTTPリクエストのAccept-LanguageヘッダーでSWATに通知される。
この機能を有効にするには以下のように行う:
適切なmsg
ファイルを、Sambaのsource/po
ディレクトリから、$LIBDIRにインストールする。
ブラウザーの言語設定を設定する。
msg
ファイルの名前はブラウザーによって送られる言語IDと同じである。
例えば、英語はen、日本語はja、
フランス語はfrである。
メッセージのいくつかが気に入らないか、使用しているロケール用のmsg
ファイルがない場合、単にen.msg
ファイルを、
“使用している言語の ID.msg”ファイル用のディレクトリにコピーし、各
“msgstr”に適切な文字列を埋める。例えば、it.msg
を
イタリア語のmsg
ファイルにするには、以下のようにする:
msgid "Set Default" msgstr "Imposta Default"
以下同様である。もしも間違いを見つけたか、新しいmsg
ファイルを作成
したならば、連絡いただければ、次のSambaリリース中に入れることを考えます。
msg
ファイルはUTF-8でエンコードされるべきである。
もしも有効にした場合、この機能とdisplay charsetがブラウザーの
設定と一致していなかった場合、SWATは不正なメッセージを表示するかもしれないことに注意。
将来のSambaのバージョンでは、SWATは常時UTF-8でエンコードされたメッセージを表示する
だろう。そうなれば、これをsmb.conf
ファイルのパラメーターとして設定する必要はなくなる。
SWATはSambaの設定に使え、Windowsネットワークの問題を解決するために便利な文書のように、 この本(ドキュメント)の内容のような、重要な参考資料への便利なリンクを得られる、 便利なツールである。
SWATタイトルページは最新のSamba文書を参照する機能を提供する。オライリーの “Using Samba”という本と同様、Samba3-HOWTO(この文書)のように、 Sambaの各コンポーネントのマニュアルページはこのページからアクセス可能である。
Sambaの設定を検証したい管理者は、診断ツールのマニュアルページから有益な情報を得ても良い。
それらはSWATホームページからも入手可能である。診断ツールのうち、このページで言及されて
いないが、特に便利なものは
ethereal
(訳注:今は
wireshark)である。
SWATはデモモードで動かすように設定できる。これは、認証なしにSWATを
動かし、完全な管理機能が使えてしまうため推奨しない。このモードでは、root特権で通常の
操作をするようにsmb.conf
を変更できる。SWATでこの機能を使うためのオプションは、
-a
フラグである。
これを動作中の環境で使ってはならない。
smb.conf
中のグローバルパラメーターの
設定が出来るページを表示する。パラメーターによって2レベルの画面がある:
共通設定オプションを表示する。
より複雑な環境で必要な設定オプションを表示する。
編集機能から他に変更するには、 ボタンをクリックする。ラジオボタンをクリックすることで行っても良い。次に、 ボタンをクリックする。
パラメーターをどこか変更した後は、他の場所に移る前に、
ボタンを押すようにすること。そうしないと変更結果は失われる。SWATは場面に応じたヘルプを提供する。各パラメーターが何であるかを調べるには、単に、 設定パラメーターの左にある
リンクをクリックする。現在設定されている共有の操作は、単に
と ボタンの間にあるプルダウンボタンをクリックし、 操作したい共有を選択する。設定を編集するには、 ボタンをクリックする。共有を削除するには、 単に ボタンをクリックする。新しい共有を作るためには、
ボタンの隣に行き、 テキストフィールドに作成する共有の名前を入力し、次に ボタンをクリックする。現在設定されているプリンターの操作は、単に
と ボタンの間にあるプルダウンボタンをクリックし、 操作したいプリンターを選択する。設定を編集するには、 ボタンをクリックする。共有を削除するには、単に、 ボタンをクリックする。新しいプリンターを作るためには、
ボタンの隣に行き、 テキストフィールドに作成する共有の名前を入力し、次に ボタンをクリックする。SWATウィザードの目的は、Microsoft系をよく知っているネットワーク管理者が、最小の手間で Sambaを設定することである。
ウィザードページは、完全に最適化した形式でsmb.conf
ファイルを再書き込みするツールである。
これは、 ボタンを押したときにも起きる。2つの違いは、
ボタンは今まで行った変更を無視するのに対し、
ボタンは今まで行ったすべての変更を反映するということである。
ボタンでは、動作するSambaサーバーを作成するために必要と思われる 最小限のオプションの編集(設定)ができる。
最後に、SambaサーバーがWINSサーバー、WINSクライアントとして参加、あるいはWINSサポートなし の、どれかタイプかに設定出来ることを決める、限定されたオプションが用意されている。 あるボタンをクリックすることで、ユーザーのホームディレクトリの表示(あるいは表示中止)を 選択できる。
ステータスページは現的な目的で提供される。最初に、これはSambaデーモンの制御を行う。 Sambaサーバー環境下で作成できるデーモンは、smbd, nmbdと winbinddである。
デーモンは、個別、あるいは全体をまとめたグループで制御できる。さらに、自動的に 画面のリフレッシュを行うタイミングを設定しても良い。Microsoft Windowsクライアントが Sambaとやりとりをするように、新しいsmbdプロセスは継続して起動される。自動画面 リフレッシュ機能は、最小の効果で変更の状態を追従できる。
最後に、ステータスページはロックされたかもしれないファイルを解放するために、特定の smbdクライアント接続を終了する事に使うことも出来る。
Table of Contents
この章には、Sambaサーバーの検証が行えるテストの一覧が含まれている。また、それらの手順の どこかで失敗した問題を起こす可能性の高いものが何かと言うことについても説明している。 もしも、すべてのテストをパスしたら、おそらく正しく動いているだろう。
すべてのテストを示された順で行うべきである。後のテストが、前のテストで確認された 機能のみを使うように、テストを注意深く選ぶようにしてある。しかし、最初のエラーで 止まってはならない:テストの継続が、問題の解決を手助けするという事例があったからで ある。
もしも、“It does not work,”というタイトルでメールをSambaメーリングリストの どこかに送り、このテスト手順に従わないならば、メールが無視されても驚いてはいけない。
すべてのテストにおいて、SambaサーバーはBIGSERVERで、PCクライアントがACLIENTで、両者とも TESTGROUPというワークグループに属していることを仮定する。
手続きは、他のクライアントのタイプと同様である。
smb.conf
中の有効な共有名も分かっているものとする。ここでの例における共有の名前は
tmp
である。これは、次の例
で示される行を追加することで、このようなtmp
共有を追加できる。
これらのテストはバージョン3.0.0以降のSambaシステムを仮定する。以前のバージョンでは いくつかのコマンドは存在しない。
受け取ったエラーメッセージに注意をはらってほしい。もしもエラーメッセージが、使用している
サーバーが調子が悪いという事を報告しているのであれば、まず初めに使用しているIPを名前解決
する方式が正しく設定されているかどうかをチェックすべきである。実際に存在している
ネームサーバーを、/etc/resolv.conf
が正しく指し示しているようにする
こと。
また、もしも、名前解決用のDNSサーバーアクセスが出来ないならば、smb.conf
に
dns proxy = no
が設定されているかをチェックする。
これをチェックする最も良い方法は、testparm smb.conf
である。
別のターミナルコンソール(X中で複数のターミナルを使うには、ctrl-alt-F1からF6を使用)で、
tail -F log_file_name
を使うことで、テストの間ログファイルをモニターする
のは便利である。適切なログファイルは(既定値によるインストールでは)、
/usr/local/samba/var
にある。また、マシンからの接続ログは、ここか、
/var/log/samba
か、あるいは
smb.conf
ファイル中でロギングを指定した場合には、それに依存する場所にある。
もしも、それらのテスト中にsmb.conf
ファイルを変更したならば、smbdとnmbdの再起動を
忘れないこと。
Procedure 38.1. 使用しているSambaサーバーの診断
smb.conf
ファイルを格納しているディレクトリ中で、testparm smb.conf
を
実行する。もしも何らかのエラーが発生した場合、そのsmb.conf
の設定には間違いがある。
PCからping BIGSERVER
コマンドを動かし、UNIXマシンから
ping ACLIENT
を動かす。正常な応答がない場合、TCP/IP層の設定が
うまくいっていない。
PC上でpingを動かす場合には、“DOS プロンプト”を起動する必要がある。
もしも、“host not found”か同様なメッセージが
表示されたならば、DNSソフトウェアか/etc/hosts
ファイルが正しく
設定されていない。もしもDNSを使っている場合、/etc/resolv.conf
に、
正しい、最新のエントリがあるかどうかをチェックする。DNSエントリなしにSambaをサーバーと
クライアントとして動作させることは可能であるが、この後のテストでは、正しいエントリが
あると仮定している。
pingが失敗するかもしれない他の理由としては、使用しているホスト上でファイアウォール
ソフトウェアが動作している場合である。ワークステーションからの問い合わせに対して
ルールをゆるめる必要がありえ、それはおそらく、他のサブネットからのアクセスを許可する
ことであろう(Linux上では、これは、ipchains
か
iptables
という、適切なファイアウォール管理コマンドによって行える)。
最新のUNIXディストリビューションでは、既定値でipchains/iptablesをインストールしている。 これは、しばしばよく見落とされる問題である。
もしも、テスト中にシステム中どのようなファイアウォールルールが存在しているかを調べたい
場合、単純にiptables -L -v
か、あるいは
ipchains
ベースのファイアウォールを使っている場合には、
ipchains -L -v
を入力する。
以下は、Sambaが有効になっていない外部向けのイーサネットインタフェース(eth1)とSambaが 有効になっている内部向けの(プライベートネットワーク)インタフェース(eth0)を持つ、 システムからの結果例である。
frodo:~ # iptables -L -v Chain INPUT (policy DROP 98496 packets, 12M bytes) pkts bytes target prot opt in out source destination 187K 109M ACCEPT all -- lo any anywhere anywhere 892K 125M ACCEPT all -- eth0 any anywhere anywhere 1399K 1380M ACCEPT all -- eth1 any anywhere anywhere \ state RELATED,ESTABLISHED Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 978K 1177M ACCEPT all -- eth1 eth0 anywhere anywhere \ state RELATED,ESTABLISHED 658K 40M ACCEPT all -- eth0 eth1 anywhere anywhere 0 0 LOG all -- any any anywhere anywhere \ LOG level warning Chain OUTPUT (policy ACCEPT 2875K packets, 1508M bytes) pkts bytes target prot opt in out source destination Chain reject_func (0 references) pkts bytes target prot opt in out source destination
UNIXマシン上でsmbclient -L BIGSERVER
を動かす。
これで有効な共有の一覧が得られる。
もしも“bad password”という文字列があるエラーメッセージが表示されたら、
不正なhosts allow
、hosts deny
か
valid users
行がsmb.conf
にあるか、ゲストアカウントが無効に
なっている。testparmでゲストアカウントが何かを調べ、一時的に
hosts allow
, hosts deny
,
valid users
, かinvalid users
行を
削除してみる。
もしも、connection refused
というメッセージが帰ってきたら、
smbd
サーバーが動いていないかもしれない。もしも
inetd.conf
経由で動作するようにしていたら、おそらくこのファイルの
編集が間違っている。もしもdaemonとして動作するようにしていたら、動作しているかを調べ、
netstat -a
を使ってnetbios-ssnポートがLISTEN中かを確認する。
ある種のUNIX/Linuxシステムでは、inetd
の代わりに
xinetd
を使っている。ネットワークスーパーデーモンの、
特定のシステム実装についての、制御ファイルの位置の説明文書を調べること。
もしも、session request failed
というメッセージが表示されたならば、
サーバーは接続を拒否している。もしも“Your server software is being unfriendly”
というメッセージが表示されたならば、それはおそらくsmbdに対するコマンドラインオプションを
間違えているか、smbdの初期起動時に同様の致命的な問題がある。testparmで設定ファイル
(smb.conf
)の文法と、ログとロックファイルを保持する種々のディレクトリもチェックする。
セッション要求を拒否するか、断るかもしれない数多くの理由がある。それらは、
次の例で示されているsmb.conf
ファイルのエントリ
によって発生する。
特定のサブネットからのみ接続を受け付ける設定例では、 ループバックアダプターアドレス 127.0.0.1へ自動的に変換される任意のセッション要求は 許可されない。この問題を解決するためには、以下の例で 示されているような行に変更する。
他の、よくある2つのエラーの例は、Samba(すでにinetd経由で
smbdが動いている)か、DECのPathworksのような、ポート139
上で
何かがすでに動いているものである。デーモンでsmbdを動かす前に
inetd.conf
ファイルをチェックすること。そうすれば
多くのトラブルを防げる!
さらに、このテストが失敗する、他のあり得そうな例としては、サブネットマスクか
ブロードキャストアドレスの設定が不正な場合である。ネットワークインタフェースの
IPアドレス、ブロードキャスト、サブネットマスクが正しいかと、それらが
log.nmbd
ファイル中に正しくSambaが記録しているかを確認すること。
nmblookup -B BIGSERVER __SAMBA__
コマンドを動かす。
使用しているSambaサーバーのIPアドレスが表示されるはずである。
そうでない場合、nmbdが駄々しくインストールされていない。inetd.conf
経由で動かしている場合はそこを、あるいはデーモンが動いていてUDPポート137をリッスン
しているかどうかをチェックする。
ある1つのよくある問題は、多くのinetdの実装が、コマンドライン上に多数のパラメーターを使えない というものである。もしもこの場合、正しいパラメーターを含む1行のみのスクリプトを作成し、 それをinetdから起動する。
nmblookup -B ACLIENT `*'
を起動する。
PCのIPアドレスが表示されるはずである。もしもそうでなければ、PC上のクライアント ソフトウェアの設定が間違っているか、開始していないか、PCの名前が間違っているか である。
もしもACLIENTがDNS経由で名前解決できない場合、上記のテストで、クライアントのIP アドレスを使用してみる。
nmblookup -d 2 `*'
コマンドを動かす。
この時点では前述のテストと同じ事を試みるが、既定値のブロードキャストアドレスに、
ブロードキャスト経由で行う。それをリッスンしているSambaは短時間にすべての応答を
受け取れないかもしれないが、ネットワーク上にある、たくさんのNetBIOS/TCP/IPホストが、
これに応答する。いくつかのホストからの、
got a positive name query response
メッセージを受け取るはずである。
もしも、上記のテストのような結果が得られないのであれば、nmblookupが、その自動
メカニズムによる、使用しているブロードキャストアドレスを正しく入手できていない。
この場合、使用するIPアドレス、ブロードキャストとサブネットマスクを、
smb.conf
中のinterfacesオプションに、手動で設定する
ことをやってみるべきである。
もしも、使用しているPCとサーバーが同じサブネットにない場合、そのPCのサブネットの
ブロードキャストアドレスを指定する-B
オプションを使う必要がある。
このテストは、サブネットマスクとブロードキャストアドレスが間違っている場合、おそらく 失敗する(3つ前の注意(Note)を参照)。
smbclient //BIGSERVER/TMP
コマンドを動かす。パスワード要求が来る
はずである。UNIXマシンにログインするアカウントのパスワードを入力する。もしも他の
アカウントで、テストを行いたいならば、コマンドラインの最後の所に、
-U accountname
オプションを追加する。 たとえば、
smbclient //bigserver/tmp -Ujohndoe
である。
以下のように、ユーザー名に引き続いてパスワードを指定することも出来る:
smbclient //bigserver/tmp -Ujohndoe%secret
.
パスワードを入力すると、smb>
プロンプトが出るはずである。もしも
そうでなければ、エラーメッセージが表示される。もしもそれが
“invalid network name”であれば、サービス
tmp
がsmb.conf
中で正しく設定されていない。
“bad password”という表示がされたならば、 あり得そうな原因は以下の通り:
shadowパスワード(かその他のパスワードシステム)を使っているが、smbd中で それをサポートするようにコンパイルされていない。
使用しているvalid usersの設定が間違っている。
大文字小文字を混ぜたパスワードを使っているが、十分に大きなレベルを password levelオプションで有効にしていない。
smb.conf
中のpath行が間違っている。testparmで
検査すること。
パスワード暗号化を有効にしているが、SambaユーザーにUNIXユーザーをマップしていない。
smbpasswd -a username
を実行する。
接続後、コマンドdir
, get
,put
などが使えるようになっているはずである。どう入力するかを調べるために、
help command
を入力する。dir
コマンドを入力した
時に、空きディスクスペースが正しいかを、特にチェックすべきである。
PC上で、net view \\BIGSERVER
コマンドを入力する。これは、DOSウィンドウ
内で入力する必要がある。サーバー上で有効な共有一覧が表示されるべきである。
network name not found
か似たようなエラーが表示された場合、NetBIOS
名前解決が動作していない。これは通常nmbd
の問題である。これを解決
するために、以下のどれかを行う(どれか1つを選ぶのみでよい):
nmbdのインストールを修正する。
PC上のTCP/IP設定中にある「詳細設定」においてwins
タブ中に
BIGSERVERのIPアドレスを追加する。
TCP/IP設定中にある「詳細設定」においてDNS経由での名前解決を有効にする。
PC上のlmhostsファイルにBIGSERVERを追加する。
もしも、“invalid network name”か
“bad password error,”というメッセージが表示された
ならば、smbclient -L
テストでのと同じ修正を行う。特に、
hosts allow
行(マニュアルページを参照)が正しいかを確認すること。
また、ワークステーションがSambaサーバーに接続を要求するとき、Windowsマシンにログオンしている 名前を使うという事実を見落とさないこと。Sambaサーバー上で存在しているアカウントと正確に 同じ名前とパスワードにする必要がある。
もしも“specified computer is not receiving requests”
か、同等のエラーが表示されたならば、おそらくTCP経由でホストに接続できないことを
意味する。TCPラッパーがホスト上で動いているかを調べ、そうであれば、クライアント
(かサブネット等)のエントリをhosts.allow
に追加する。
net use x: \\BIGSERVER\TMP
を実行する。パスワード要求が来るはずである。
次に、command completed successfully
メッセージが表示
されるはずである。そうでない場合、PC上のソフトウェアが正しくインストールされていないか、
smb.conf
が間違っている。smb.conf
中のhosts allow
と他の
設定行が正しいかを確認する。
サーバーが、どのユーザー名で接続するかを見いだせないという事もあり得る。この問題かどうかを
見るためには、smb.conf
中の[tmp]
セクションに
user = username行を追加する。ここで、
username
は、入力するパスワードに対応するものである。
もしもこれで修正されるならば、ユーザー名マッピングオプションが必要となるかもしれない。
クライアントが暗号化パスワードのみを送り、smb.conf
中で
encrypt passwords = noが設定されているという
場合もあるかもしれない。これを修正するためには、設定を`yes'に変更する。
ワークグループの名前がtestgroup
である、SambaサーバーとWindows PCが
属している所でnmblookup -M
を
実行する。そのワークグループにおけるマスターブラウザーのIPアドレスが表示されるはずである。
testgroup
そうでない場合、選択プロセスが失敗している。ただ単に遅れているのかもしれないので
しばらく待ち、再度試してみる。それでも失敗した場合、smb.conf
中にある
ブラウジングオプションを調べてみる。起動時に選択(election)が行われるように、
preferred master = yesを書いておくこと。
ファイルマネージャから、サーバーをブラウジングしてみる。ローカルワークグループ
(かsmb.conf
中で指定したもの)のブラウズリスト中にSambaサーバーが現れるはずである。
サーバーの名前をダブルクリックし、共有の一覧が得られるべきである。もしも、
“invalid password”というエラーが表示されたならば、おそらくWindows NTが
動作していて、それがユーザーレベルのセキュリティモードで動作していて暗号化パスワードを
扱えない状態になっていてサーバーのブラウジングを拒否している。この場合、
security = serverと
password server = Windows_NT_Machineのどちらかを
smb.conf
ファイル中に設定するか、encrypt passwordsを
“yes”に設定するようにする。
Table of Contents
メーリングリスト、RFCやドキュメントのような形で、数多くの情報源が存在している。Sambaの 配布物に由来するドキュメントには、ブラウジングのような一般的なSMBのトピックについての 良い説明が含まれている。
SMBネットワーキングにおいて、特定の問題について、何が原因かと言うことが、簡単に 分からないことがよくある。Sambaそれ自身はむしろ役立つ情報を提供するが、いくつかの 例では、snifferを使った方がよいかもしれない。snifferは LANをモニターし、そこに送信されているデータを解析し、画面上に表示するプログラムである。
問題をデバッグするための最も良い診断ツールの1つは、Sambaそれ自身である。動作するときの、
debug levelを、smbdとnmbd両方に指定する、
-d オプション
が使える。smbd, nmbd
とsmb.conf
の
マニュアルページに、デバッギングオプションに関連するより詳細な情報があるので参照すること。
debug level(log level)は1(既定値)から10までを指定できる(100はパスワードデバッグ用)。
別の、デバッギングに便利な方法は、gcc -g
フラグ付きでSambaをコンパイル
することである。これは、バイナリ中にデバッグ情報を埋め込み、動作中の
smbd/nmbd
プロセスにgdb
がアタッチできるようにする。
NTワークステーション向けに、あるsmbd
プロセスにgdb
を
アタッチするためには、最初にワークステーションとの接続を確立する。
LsaEnumTrustedDomains
を生成するのに、ctrl-alt-deleteを
押し、ドメインログオン画面を表示すれば(少なくとも、最初にドメインに参加しておく)
十分である。その後、ワークステーションは開いているコネクションを維持し、smbdプロセスが
走り出す(短い、smbdのアイドルタイムアウトを設定していないと仮定する)。
ctrl-alt-delete
を押してからパスワードを実際に入力するまでの間に、
gdb
をアタッチでき、そのあと継続できる。
調べてみる価値のある便利なSambaのコマンドのいくつかは以下の通り:
$
testparm | more
$
smbclient -L //{サーバーのnetbios名}
TcpdumpはSMBをサポートした最初の
UNIX上でのsnifferである。これはコマンドラインユーティリティで、現在、そのSMB
サポートは、ethereal
やtethereal
よりは
若干遅れている。
Etherealは、GUIのsnifferで、UNIX(Gtk)
とWindows両方で使える。EtherealのSMBサポートはとても良い。ethereal
の
使用法の詳細は、良くできているEthereal User Guideを読むこと。
ポート137,138,139,445をリッスン。例えば、キャプチャの開始
画面であるように、port 137, port 138,port 139,か port 445
を
フィルタとして使う。
tethereal
という名前のコンソールバージョンのecherealもある。
Microsoft Windows NT上での同等品は、ネットワークモニター(Netmonとして知られる)が、 Microsoft Developer Network CD、Windows NTサーバーインストールCDとSMSのCD中ににある。 SMSに同梱されているnetmonは任意の2つのコンピュータ間のパケットをダンプできる(すなわち、 ネットワークインタフェースをpromiscuousモードにする)。NTサーバーインストールCDに同梱 されているものは、ローカルのNTマシンに直接来るネットワークトラフィックとローカルな サブネットのブロードキャストのみモニターできる。etherealはnetmon形式のファイルを読み書き 出来る事に注意。
NTワークステーション上へのインストールには、多くの手順が必要である。以下は、 Microsoft Windows Workstation 4.0上にMicrosoft Windows NT Server 4.0から持ってきた Netmon V4.00.349をインストールする手順である。この手順はNetmonの、他の Windows NTバージョンからのものと同等である。Microsoft Windows NT Server 4.0 インストールCDとWorkstation 4.0のインストールCDの両方が必要である。
最初に、以下のようにして、NTサーバー上にネットワークモニターツールとエージェント をインストールする必要がある:
-> -> -> -> -> を表示する。
ネットワークモニターツールとエージェントを選択し、 を クリックする。
ネットワークコントロールパネル上の
をクリックする。要求されたならば、Microsoft NT Server 4.0のインストールCDを挿入する。
この時点で、Netmonファイルは%SYSTEMROOT%\System32\netmon\*.*
に
存在すべきである。Netmonがパケットダンプを解析するために必要なDLLを含む
parsers\
と、captures\
という2つのサブ
ディレクトリも同様に存在する。
NT ワークステーション上にNetmonをインストールするためには、ワークステーションインストール CDかr、ネットワークモニターエージェントを最初にインストールする必要がある。
-> -> -> -> -> を表示する。
ネットワークモニターエージェントを選択し、 をクリックする。
ネットワークコントロールパネル上の
を クリックする。要求されたならば、Windows NT Workstation 4.0インストールCDを挿入する。
そうすると、ワークステーション上の%SYSTEMROOT%\System32\netmon
に、
NTサーバー上の%SYSTEMROOT%\System32\netmon
からファイルをコピーし、
使用しているサイトに適切と見なされるアクセス許可を設定する。NetmonをNTマシン上で
動作させるには、管理者権限が必要である。
BDCの動作をScott Merrillがシミュレートしたかについては http://www.skippy.net/linux/smb-howto.htmlを参照(訳注:現存せず)。
古いSMBの仕様については ftp://ftp.microsoft.com/developr/drg/CIFS/というFTPサイトにある(訳注:現存せず)。
Sambaに関連した数多くのメーリングリストがある。
http://samba.orgに移動し、
最も近いミラーサーバーを選択し、Support
をクリックする。次に、
Samba-related mailing lists
をクリックする。
Samba TNGに関連する質問は、 http://www.samba-tng.org/にある。 メインストリームのSambaメーリングリストには、Samba-TNGに関連する質問を投稿しない こと。
メーリングリストのどれかに投稿したいのであれば、以下のガイドラインをよく読んでほしい:
いつも覚えておいてほしいのは、開発者はボランティアであるということである。 ある時点までに特定の機能を作る事について、開発者はお金をもらっているわけでも、 保証しているわけでもない。どの予定も“希望的観測”であり、それ以上の ものではない。
常時、どのバージョンのSambaを使っていて、それが動いているOSが何かと言うことを
説明すること。使用しているsmb.conf
の適切なセクションを、少なくともPDCサポートに
影響する[global]
中のオプションは提示すること。
バージョンについては、もしもCVS(訳注:現在はgit)経由でSambaを 入手したならば、最後にチェックアウトした日付を提示すること。
質問を明確に、手短にするよう心がけること。とても長い、複雑な 質問は、それが完全に読まれる前に捨てられてしまう!HTMLエンコードして投稿しないこと。 メーリングリストを購読しているほとんどの人は、それを読まないで捨ててしまう。
もしも、不在時に、“ただいま留守にしております” というような気の利いたメッセージを返しているのであれば、メーリングリストに 返信しないように設定すること。メーリングリストへの自動応答は、このような ネット上での好まれない対応に応対しなければならない、何千もの人々をいらつかせて しまう。
クロスポストしないこと。どのメーリングリストが最適かを調べて投稿し、何が 起きたかを確かめてみること。samba-ntdomとsamba-technical両方に投稿しないこと。 多くの人は、1つ以上のメーリングリストに参加していて、2回以上同じ記事を 見るといらだってくる。他のメーリングリストで、記事を取り扱った方がよいと 考えている誰かは、しばしばその投稿記事を転送してくれている。
おおよそ20でログレベルが設定されて記録されたログファイルを 部分的に含めても良い。ログ全体を送ってはならないが、 エラーメッセージが分かるためのひとまとまりの部分ならばよい。
もしも、完全なNetmonトレース(開始からエラー時点まで)が あるならば、同じように*.CAPファイルを投稿しても良いだろう。
メールにドキュメントを添付する前に熟考すること。投稿記事
本体中に適切な部分を貼り付けることを考えること。Sambaメーリングリストは
とても多くの人に配信している。使用しているsmb.conf
のコピーが、すべての
人に必要だろうか?
Sambaメーリングリストから脱退するには、参加申し込みをしたと同じページ、
http://lists.samba.org
の最も近いミラーに行き、Support
をクリックし、
Samba-related mailing lists
をクリックする。
脱退方法についてメーリングリストに投稿しないこと。(何らかの理由で処理がうまく 行かなかった場合を除いて)上記のアドレスのみを参照すべきである。
SambaのBugzilla機能を使って バグを報告し、また、報告を投稿する前に、この章を読んでほしい。また、 もしも、リリース間での変更があるかと、同様にある時点でバグ報告機能を 変更したかもしれないことを調べてほしい。
自分自身で出来るだけバグを追い詰めてほしい。Sambaは、ボランティアで時間、技術、労力を 提供している自主的なグループによって保守されている。問い合わせに対応しきれないメールを 受け取っているので、早く修正できる形で、“開発者にわかりやすい”バグ報告を 送ってもらえると、返事とバグ修正の機会が大きくなる。
もしも、comp.protocols.smbニュースグループか、メーリングリストに投稿した 場合、それを開発者が読むと思ってはいけない。もしも、問題がバグではなくて、 設定の問題だと推測したならば、手助けできる人がたくさんいるSambaメーリング リストに送った方がよい。
http://samba.org/samba/の、 Samba Webページ上で便利にアクセスできる、最近のメーリングリストアーカイブを見る事を 好むかもしれない。
バグレポートを投稿する前に、エラーに対する設定を確認する。設定を間違えていると いう明確なメッセージをログファイルの中でサポートする。正しい文法になっているか、 設定ファイルをtestparmでチェックする。
Sambaチェックリストを見てみたか?これはとても 重要である。
もしも、バグレポートの中にログファイルを含めるならば、その時点でクライアント上で 何をしたかということを正確に、その結果が何であるかを正確に注釈を付けること。
もしも、バグが、サーバーとしてSambaの正しくない動作を何かしているならば (例えばファイルのオープンを断るなど)、ログファイルがとても便利に使えるだろう。 現象にもよるが、ログレベル3から10の間が、適切に問題を表示するかもしれない。 より大きなレベルはより詳細な結果が得られるが、とてもたくさんのディスクを 消費する。
debug levelを設定するには、smb.conf
中でlog levelを指定する。
また、特定のマシンだけログレベルを大きくし、各マシン毎に分離すると便利である。
これを行うには、smb.conf
中に以下の行を追加する:
log level = 10 |
log file = /usr/local/samba/lib/log.%m |
include = /usr/local/samba/lib/smb.conf.%m |
かつ、希望するコマンドを含むsmb.conf
を、新たに
/usr/local/samba/lib/smb.conf.
として
作成する。例えば、log levelは便利に使えるだろう。
これはまた、異なったセキュリティシステム、プロトコルレベルなどを1つのマシン上で
体験することもできる。
machine
smb.conf
のエントリlog levelは、古いバージョンのSambaで
使われていたパラメーターdebuglevelと同義語であり、
smb.conf
ファイルの下位互換性のためにそのまま残っている。
log levelの値を大きくすると、きわめて大量のデバッグ情報を
記録することになる。多くのデバッグ作業において、この値を3
より
大きくする必要はないだろう。値を10
にすると、ほとんどすべての
バグが記録されるが、大きなログデータ領域を準備する必要がある。
Samba-3.xはすべての操作に対する詳細なログが書かれるログファイル中で、 必要のない項目を外して特定の機能コンポーネントだけをデバッグ(ロギング)する ことができる。これを行うための設定例は以下の通り:
log level = 0 tdb:3 passdb:5 auth:4 vfs:2 |
max log size = 0 |
log file = /var/log/samba/%U.%m.log |
これは、上記で示されている値毎に各機能単位にデバッグクラス(ログレベル)を
渡すために詳細なレベルを拡張している。log level
の
0
という最初の値は、特定の機能単位に対するデバッグクラスを
除き、すべての不必要なデバッグ出力を抑止する。
デバッグ単位の表は、Sambaが処理している各SMB
操作をとても正確に分析するのに使うことが出来るかもしれない。
Table 40.1. デバッグ単位
機能名 | 機能名 |
---|---|
all | passdb |
tdb | sam |
printdrivers | auth |
lanman | winbind |
smb | vfs |
rpc_parse | idmap |
rpc_srv | quota |
rpc_cli | acls |
もしも、ログファイル中に、“INTERNAL ERROR”という メッセージがあったら、これはSambaが動作中に予期しないシグナルを受け取ったことを意味する。 これはおそらくセグメンテーションフォルトで、多くの場合Sambaのバグである(ハードウェア の故障かシステムソフトゥエアのバグを除く)。
メッセージがsmbd由来であれば、smbが受け取った最後のSMBメッセージを詳細に説明する メッセージがおそらくあるだろう。この情報は、問題を解析するのにしばしば便利であるので、 バグレポートの中に一緒に入れてほしい。
もしも可能ならば、どのように問題を再現するかについての詳細も説明してほしい。 適度に詳細を記述してほしい。
Sambaログファイルが保存されているディレクトリのcorefiles
サブ
ディレクトリにコアファイルが存在する場合があるかもしれない。このファイルは、
バグを追跡するのに最も便利なものである。これを利用するには以下のようにする:
$
gdb smbd core
smbdとcoreに対する適切なパスを追加すると、gdbはそれらを扱えることが出来る。
もしもgdbを用意していないならば、dbx
を試してみること。
デバッガー内でwhere
コマンドを使うと、どこで問題が発生したかの
トレースが得られる。これをレポートに含める。
もしも、何らかのアセンブラ言語について知っているならば、どこで問題が発生したか
を(もしもそれがライブラリルーチン内ならば、それを呼び出しているルーチンを
逆アセンブルする)、disass
で逆アセンブルし、そのコードの周辺を
調べることで、正確にどこで現象が起きたかを調べてみる。アセンブラ言語について
知らなくても、逆アセンブル結果をバグレポートに含めることは解析に役に立つ。
不幸にも、いくつかのUNIX(特に最近のLinuxカーネルのいくつか)は、タスクがUIDを
変えたとき(smbdはしばしばこれを行う)コアファイルの作成を抑制する。
このような種類のシステムでデバッグするには、まず、
smbstatusでPID
を得、
次に、gdb smbd
を使って、稼働中のプロセスにアタッチしてみる。次に、PID
c
を使って処理を続行し、クライアントを使ってコアダンプを起こさせる。
デバッガーはフォルトを受け取り、どこでそれが起こったかを表示する。
時には、Samba Teamに問題を修正してもらうために、クラッシュした操作からの十分な情報を キャプチャすることを可能とさせるために、デバッグシンボルを持つSambaバイナリファイルを 構築する必要がある。
-g
オプションを付けてコンパイルすると、シンボルが埋め込まれる。
以下の行を、smb.conf
ファイルのグローバルセクションに追加する:
panic action = "/bin/sleep 90000"
これにより任意のパニックをキャッチできる。もしも、smbd
が
固まってしまったように見えたら、sleepしているプロセスを捜す。もしも存在せず、
空回りしてるように見えたら、空回りしているように見えるプロセスのPIDを調べ、
以下のように入力する:
root#
gdb /usr/local/samba/sbin/smbd
次に、“attach `pid'”(pidは空回りしているプロセス)を行い、次に コールパス中のどこにsmbdがいるかを見るために“bt”を入力して バックトレースを取る。
Table of Contents
Samba は軽量なデータベース Trivial Database (tdb) を利用する。一時的や 永続的なデータをそこに格納する。 一部の tdb ファイルは Samba を再起動する前に破棄できるが、その他は Samba の設定や振る舞いにとって重要な情報を格納するために利用される。 Samba のインストールについてよりよい管理を摸索している 管理者の助けとなるように下記の情報は提供される。
OSとともに商用ディストリビューションにSambaをパッケージする場合とアプライアン スの場合、十分に注意するとよいだろう。 tdb ファイルは破損することがあるため定 期的にバックアップするべきである。適切なタイミングはシステムシャットダウン(バ ックアップ)とスタートアップ(バックアップからのレストア)である。
Table 41.1. Samba の Trivial Database ファイル
ファイル名 | 要保存 | 説明 |
---|---|---|
account_policy.tdb | 要 | たとえばパスワード有効期限などのようなNT アカウントポリシー 設定など。 |
brlock.tdb | 不要 | バイトレンジロック。 |
browse.dat | 不要 | ブラウズリスト - 自動的に再構築される。 |
connections.tdb | 不要 | 各共有への接続。最大接続数までに制限するためなどに利用される。 |
gencache.tdb | 不要 | 汎用のキャッシュ用データベース。 |
group_mapping.tdb | 要 | グループマッピング情報を格納する。LDAP バックエンドを利用する際には使わない。 |
lang_en.tdb | 要 | 使用する言語のエンコーディング情報を格納する。 |
locking.tdb | 不要 | 共有モードと oplock 情報を格納する。 |
login_cache.tdb | 不要 | パスワードの失敗のログを保管する。 |
messages.tdb | 不要 | Samba 内部メッセージングの追跡に使用する。 |
netsamlogon_cache.tdb | 要 | ドメインメンバーからのリクエストnet_samlogon() からのユーザー net_info_3 構造体のキャッシュ。 |
ntdrivers.tdb | 要 | インストールされたプリンタードライバー情報を格納する。 |
ntforms.tdb | 要 | インストールされたプリンターのフォーム情報を格納する。 |
ntprinters.tdb | 要 | インストールされたプリンター情報を格納する。 |
printing ディレクトリ | 要 | キャッシュされた lpq 出力のプリントキュー毎の tdb ファイルを含むディレクトリ。 |
registry.tdb | 要 | Windows レジストリスケルトン(regedit.exeを経由して接続)。 |
sessionid.tdb | 不要 |
|
share_info.tdb | 要 | 共有レベルの ACL 構成設定を格納する。ACLの既定値は 全員 - フルコントロールである。 |
unexpected.tdb | 不要 | 発信リクエストとは異なるポートへ返信する Windows クライアントを サポートするため予期せぬパケットのキュー。 |
winbindd_cache.tdb | 不要 | Winbind のユーザーリストのキャッシュ。 |
winbindd_idmap.tdb | 要 | Winbind の ローカル IDMAP データベース。 |
wins.dat | 不要 |
|
wins.tdb | 要 |
全ての WINS データのための作業用の永続的なストレージ。 |
secrets.tdb | 要 |
この tdb ファイルは内部設定を格納する、例えば machine/domain SID、
LDAPと共に使われる秘密パスワード、machine 秘密トークンなど。
これは安全な場所に格納される必須ファイルである。ベンダーはこの
ファイルを様々なフォルダーに配置する。 |
schannel_store.tdb | 要 | SMB 署名と共に利用されるセキュア channel アクセストークン情報を格 納する。 |
passdb.tdb | 要 | tdbsamパスワードバックエンドを利用する場合、Samba の SAM アカウン ト情報を格納する。 |
tdbbackup
ユーティリティは samba の tdb ファイルをバック
アップすることに使うツールである。
Samba の起動の前または正常稼働中に tdb ファイルの完全性を診断することにも
利用することができる。
ファイルにダメージを見つけると以前のバックアップを探す。ダメージを受けた
tdb ファイルのバックアップファイルがリストアされる。
tdbbackup
ユーティリティは、いつでも安全に実行できる。
Samba が実行中であっても、どんな時でも tdb ファイルの完全性が確認できるよう
に設計された。
Samba サーバー上では Samba のスタートアップスクリプトの一部分としてすべての tdb ファ イルをバックアップすることが推奨される。 以下のコマンドシンタックスが利用できる:
myserver# > cd /var/lib/samba myserver@ > tdbbackup *.tdb
既定の拡張子は.bak
である。
tdbbackup -s 'new_extension' *.tdb
とスタートアップスクリ
プトで実行することで他の拡張子を指定することができる。
Table of Contents
Table of Contents
Samba Web siteからSambaソースファイルを
入手できる。開発バージョンのSambaは、Subversionかrsync
を使って
入手できる(訳注:現在はgit)。
(訳注:この節は現在古くなっている) Sambaは公開された環境で開発されている。開発者はSubversionを使って、新しい ソースコードを“checkin”(“commit”としても知られる) する。Sambaの種々のSubversionブランチはこの章で説明される手順で匿名 Subversion経由でアクセスできる。
この章は、Samba Webサイトにある手順を変更したものである。
samba.orgのマシンはSamba,rsync,distcc, ccacheとjitterbugを含むいくつかのパッケージの ソースコードへアクセスできるSubversionリポジトリに自由にアクセスできるサーバーを動かして いる。このホスト上のSubversionサーバーにアクセスするには2つの方法がある。
お好みのWWWブラウザー経由でソースコードにアクセスできる。これにより、リポジトリの 個別のファイルの内容、リビジョン履歴、特定のファイルに対するコミットログに アクセスできる。リポジトリ上の任意の2つのバージョン間での差分表示を得ることもできる。
http://viewcvs.samba.org/ を使うこと。
通常のSubversionクライアント経由でソースコードにアクセスすることもできる。そうすると、 リポジトリに対してより多くの制御ができ、完全なソースコードツリーをチェックアウトでき、 通常のSubversionコマンド経由で最新版に追従できる。もしもあなたが開発者であれば、 これは好ましいアクセス方法であり、通常のブラウザーは好ましくない。
SubversionでSambaのソースをダウンロードできるように、するためには、Subversion クライアントが必要である。使用しているディストリビューションに入っているかもしれないし、 そうでなければ、 http://subversion.tigris.org/ からソースをダウンロードできる。
匿名Subversion経由でアクセスするためには、以下のステップを使う。
Procedure 42.1. Subversionを使うSambaの検索
最新のSubversionのコピーをインストールする。必要なものすべては、 Subversionクライアントバイナリのコピーである。
以下のコマンドを動かす
svn co svn://svnanon.samba.org/samba/trunk samba
.
これは、最新のSambaソースコード(通常次のメジャーリリースになるブランチ)を含む、
samba
と呼ばれるディレクトリを作成する。これは現在
3.1開発ツリーに連動している。
trunk以外のSubversionブランチは、チェックアウトするときに、branches/BRANCH_NAME というURLによって得られる。ブランチ名の一覧は、Samba Webサイトの “Development”のページから得られる。最新の3.0リリースコードを得たい という共通の要求がある。これは以下のコマンドを使うことによってできる:
svn co svn://svnanon.samba.org/samba/branches/SAMBA_3_0 samba_3
.
最新のコードの変更にマージしたい場合は、Sambaディレクトリ内で以下のコマンドを使う:
svn update
pserver.samba.org
も、
pserver
というSambaのサイトの所から、Subversionツリーのほとんどの部分のパックされてない
コピーをエクスポートでき、また、
rsync
という、Sambaの匿名rsyncサーバー経由でも同じようにできる。ftpよりはrsyncの方が、
rsyncはデータを圧縮転送できるのでお勧めであり、また、抜けているデータのみを
転送出来るという、部分更新が出来て、オーバーヘッドが少ないという点でもお勧めで
ある。rsyncについてのより詳細な情報は、
the rsync home page
を参照のこと。
アンパックされたツリーの欠点は、Subversionのように、ローカルな変更の自動マージを
サポートしないと言うことである。rsync
によるアクセスは、
初期導入に最も便利である。
インストールする前に、任意のソースファイルのPGP署名を検証することを強く推奨する。 ミラーサイトからダウンロードしていないとしても、PGP署名の検証は、標準的な習慣と すべきである。多くの人は現在PGPの代替としてGNU GPGツールを使っている。GPGは PGPの代わりとして使える。
そんなわけで、以下のようにしてファイルをダウンロードする:
$
wget http://us1.samba.org/samba/ftp/samba-3.0.20.tar.asc
$
wget http://us1.samba.org/samba/ftp/samba-pubkey.asc
最初のファイルはSambaソースファイルのPGP署名である。もう1つはSambaの公開PGPキーそれ自身 である。以下のようにしてPGPキーをインポートする:
$
gpg --import samba-pubkey.asc
そして、Sambaソースコードの正当性を以下のようにして検査する:
$
gzip -d samba-3.0.20.tar.gz
$
gpg --verify samba-3.0.20.tar.asc
もしも、“Good signature from Samba Distribution Verification Key...,” というようなメッセージが表示されたならば、すべて問題はない。信頼性の関係についての 警告は無視して良い。以下のような表示が出たら問題である:
gpg: BAD signature from “Samba Distribution Verification Key”
tar形式のソースコードを展開後、次のステップは、使用しているOSプラットフォームに
Sambaが適合するように、設定(configuration)を行う。もしもソースディレクトリが
configure
スクリプトを含んでいないのであれば、以降を行う
ために、構築作業が必要である。configureスクリプトの構築はautoconfの正しい
バージョンが必要である。ど必要とされるバージョンのautoconfがある場合、
以下を実行して生成されるスクリプトでconfigureスクリプトを生成できる。
root#
cd samba-3.0.20/sourceroot#
./autogen.sh
バイナリを構築するためには、ソースディレクトリ中で、
./configure
プログラムを動かす。これは、使用している
OS用にSambaを自動的に設定する。もしも特別な要求があるならば、最初に
以下のように起動しても良いだろう:
root#
./configure --help
これは、どのような特別なオプションが有効に出来るかの一覧を表示する。その後、
必要な任意の引数を付けて、./configure
を実行する:
root#
./configure
[... arguments ...]
root#
make
一度コンパイルが成功すると、以下のようなコマンドを実行することで、 バイナリとマニュアルページをインストールできる:
root#
make install
ある人は、バイナリファイルとマニュアルページを分離してインストールすることを 好んでいる。もしもそうしたいのであれば、以下を実行することで、バイナリファイルを インストールできる:
root#
make installbin
マニュアルページは以下のコマンドでインストールできる:
root#
make installman
もしも、以前のバージョンからアップグレードするのであれば、古いバージョンの バイナリは“.old”という拡張子を付けて改名される。 以下を実行することで、前のバージョンに戻ることが出来る:
root#
make revert
上記を見て分かるとおり、Sambaの構築とインストールは災難を引き起こす事はない!
ADSをサポートするようにSambaをコンパイルするためには、以下のものをシステムに インストールする必要がある:
MIT あるいは Heimdal Kerberos開発ライブラリ (ソース、あるいはパッケージからのどちらかからインストール)
OpenLDAP開発ライブラリ。
もしも、使用しているKerberosライブラリが標準でない位置にあるならば、
以下のconfigure オプションを追加するのを忘れないこと。
--with-krb5=
.
DIR
configrue を実行後、生成されたinclude/config.h
が、
以下のような行を含んでいるかを確認する:
#define HAVE_KRB5 1 #define HAVE_LDAP 1
もしもそうでない場合、configureはインストールされているKRB5ライブラリか
LDAPライブラリを見つけるのに失敗している。なぜそうなったかを
config.log
をみて確認して修正する。
Red Hat Linuxでは、少なくとも:
krb5-workstation (for kinit)
krb5-libs (for linking with)
krb5-devel (because you are compiling from source)
を標準開発環境に追加する必要があることを意味する。
もしも、使用しているシステム上にこれらのファイルがインストールされて いないならば、どこにそれらがあるかをインストールCDでチェックすべきであり、 使用しているツールにあわせてインストールする。もしもどのツールが使っている かが分からない場合は、Red Hat Linuxのドキュメントを参照すること。
SuSE Linuxはバイナリパッケージを構築する事が出来るのに必要とされるだろうHeimdal パッケージをインストールする。使用しているシステム上に、開発ライブラリが インストールされているかを調べるべきである。
SuSE Linux のSamba RPMはKerberosをサポートする。SuSE Linux固有の設定に関連する 情報は、使用しているSuSE Linuxシステムのドキュメントを参照して欲しい。さらに、 SuSEは使用可能な機能を最大限提供するように、Sambaパッケージのメンテナンスをとても 頻繁に行っている。使用可能な、SuSEが提供しているパッケージの使用について考慮 すべきである。
smbd, winbindd と nmbdの起動を、デーモンかinetd
からの起動のどちらかにするかを選ぶ必要がある。両方同時に行ってはいけない!
inetdによって必要時に起動するように、
inetd.conf
にそれらを記述するか、コマンドラインか、
/etc/rc.local
に記述することで、デーモンとして起動できる。
コマンドラインオプションの詳細についてはマニュアルを参照のこと。どのユーザーで
Sambaを起動する必要があることについての部分を注意深く読むこと。ほとんどの場合、
rootで起動する必要がある。
推奨される、デーモンによる方法を使ってsmbd と nmbdを開始することの利点は、 最初の接続要求時に、若干より迅速に反応すると言うことである。
以下は、もしもNIS、NIS+あるいはLDAPが分散されたサービスマップを 使っている場合は異なる。
/etc/services
を見る。ポート139/tcpに何が定義されて
いるだろうか?もしも何も定義されていないならば、以下のように行を追加する:
netbios-ssn 139/tcp
137/udpに対して、以下のようなエントリを同様に追加する:
netbios-ns 137/udp
次に、/etc/inetd.conf
を編集し、以下のように2行追加する:
netbios-ssn stream tcp nowait root /usr/local/samba/sbin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/sbin/nmbd nmbd
/etc/inetd.conf
の正しい文法はUNIX毎に異なる。ガイドの
inetd.conf中の他の項目を参照すること。
いくつかのディストリビューションはinetdの代わりにxinetdを使っている。 設定情報についてはxinetdのマニュアルを参照すること。
いくつかのUNIXではすでに/etc/services
中に
netbios_ns(下線に注意)のようなエントリが存在している。整合性を取るために、
/etc/services
か/etc/inetd.conf
を
編集する必要がある。
多くのシステムでは、使用しているネットワークインタフェースのIPアドレスと
ネットマスクを指定するために、 smb.conf
中で
interfacesオプションを使う必要があるかもしれない。
使用しているネットワークでの、ブロードキャストが何であるかを知らないのであれば、
rootでifconfigを起動する。nmbdは実行時にそれを
決めようとするが、ある種のUNIXでは失敗する。
多くのUNIXは、inetd.conf
中で、コマンドライン上におおよそ
5つのパラメーターのみを受け付ける。これは、オプションと引数間でスペースが使えない
という事を意味するので、そうしたくなければ、スクリプトを使い、
inetd
経由でスクリプトを起動する。
おそらく以下のようにHUPを送ることで、inetdを 再起動する:
root#
killall -HUP inetd
サービスをデーモンとして起動するには、startsmb
という、
下記のようなスクリプトを作成すべきである。
#!/bin/sh /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/winbindd -D /usr/local/samba/sbin/nmbd -D
chmod +x startsmb
でこれを実行可能にする。
手動か、/etc/rc.local
からstartsmb
を
実行することが出来る。
これを停止するには、プロセスnmbd と smbdにkillシグナルを送る。
もしも、SVR4形式のinitシステムを使っているならば、そのシステムにSambaを
適合するように、examples/svr4-startup
スクリプトを
みてやってもよいだろう。
Red Hat Linuxは標準的なインストール状態ではすべてのSambaコンポーネントが
常時含まれるわけではない。そのためRed Hat Linuxのバージョンによっては、
インストールCDROMメディアにあったとしても、winbindユーティリティをインストール
しない。システム上にwinbindd
があるかをチェックすること:
root#
ls /usr/sbin/winbindd
/usr/sbin/winbindd
これは、適切なRPMパッケージがインストールされていることを意味する。以下の応答は、 インストールされていない場合である:
/bin/ls: /usr/sbin/winbind: No such file or directory
この場合、winbindd
を使うつもりであるならば、インストールが
必要である。samba-winbind RPMをCDROMインストールメディアから捜し、以下の
Red Hatガイドラインに従ってインストールする。
Sambaの起動の手順の概要を以下で説明する。Sambaを起動する前に、Sambaの
smb.conf
をきちんと設定しておくこと。設定後、以下のようにしてSambaを
起動する:
root#
service smb startroot#
service winbind start
このステップで nmbd, smbd と winbinddを起動する。
システムが再起動したときに、自動的にこれらのサービスが再起動するようにするには、 以下を実行する:
root#
chkconfig smb onroot#
chkconfig winbind on
Sambaは毎再帰同時に自動的に起動するようになる。
Novell SuSE Linux 製品は自動的にすべての基本的なSambaコンポーネントを既定値の
インストール作業でインストールする。smb.conf
ファイルを設定後、以下を行う
事でSambaを起動する:
root#
rcnmb startroot#
rcsmb startroot#
rcwinbind start
以下のコマンドを実行後、Sambaはシステム再起動後に自動的に起動する:
root#
chkconfig nmb onroot#
chkconfig smb onroot#
chkconfig winbind on
これで、Sambaサーバーはシステム再起動後に自動的に起動する。
Samba は広い範囲のプラットフォームで機能する。しかし、すべてのプラットフォー ムの提供するインタフェースが常に互換性があるとは限らない。 この章は Samba のコンパイルと利用についてプラットフォームに特化した情報を含む。
(歴史的な理由により)HPでは、補助グループの実装が非標準である。
グループファイルには/etc/group
と
/etc/logingroup
の2つがある。
システムは、UIDから番号(訳注:GIDのことか)を前者のファイルを使用して割り当てるが、
initgroups()は後者を参照する。
コツを知っている大抵のシステム管理者は、シンボリックリンク
/etc/group
を /etc/logingroup
へ張る
(ここに記述することができない愚鈍な理由でハードリンクでは機能しない)。
initgroups()は、/etc/logingroup
の中で所属しているグループ
に不正なIDがあればエラーを出す。
ここで言う不正なIDとは [0..UID_MAX]
の範囲を超えた場合
であり、HP-UX のUID_MAX
は現在のところ60000である
(訳注:HPのページで見る限り、現在は2147483647)。
この範囲は、-2 と 65534 を除外している。これは通常 nobody
の
GIDである。
もしこの問題に遭遇した場合、initgroups()に失敗するプログラムを実行している ユーザーが、許可された範囲外の GID のグループユーザーでないことを確認すること。
このことは、HPのマニュアルページ setgroup(2)とpasswd(4)に記述されている。
HP-UXでは、gccまたはHP ANSIコンパイラを利用しなければならない。 HP-UXに付属する無償のコンパイラは ANSI に準拠していないためSambaをコンパイ ルできない。
もし古いバージョンのSCO UNIXを稼働させているのなら、Sambaを正常に 機能させるためには、TCP/IPの重要なパッチを入手する必要があるだろう。 そのパッチがないと、Sambaを利用している際に転送データが破損する。
必要とするパッチは UOD385 Connection Drivers SLSである。 SCOftp.sco.com から ディレクトリSLSの中にある、ファイル uod385a.Z と uod385a.ltr.Z が当該のものである。
ここで提供される情報は、SCO UNIXの古いバージョンを参照している。 もしより新しいSCO UNIX のバイナリが必要ならば、インストール可能なパッケージを 入手するためSCOに連絡すること。 インストールするバイナリのためプラットフォームが最新であることも、SCOで確認 しなければならない。 これは、インストール作業にてデータ破損を避けるために重要なことである。 SCO UNIX製品用にSambaをビルドする場合、 Samba のソースに大幅なパッチが 必要となるかもしれない。 SCO から直接バイナリパッケージを入手する方がとても容易である。
DNIX は seteuid() と setegid() に問題がある。これらのルーチンはSambaが正しく 機能するために必要である。しかし、それらはいくつかの理由によりDNIX の Cライブラリ から抜け落ちている。
この理由により、Sambaはincludes.hのDNIXセクションにて、既定値でNO_EIDマクロを 定義している。この問題について、限られた方法ではなんとか機能する。しかし理想からは 程遠く、いくつかの事柄はまだ正しく機能しないだろう。
この問題を正しく解決するため、以下の2つの関数をアセンブルする必要がある。
そしてそれらをCライブラリに加えるか、Sambaにリンクすること。
以下のコードを setegid.s
の中に記述する。
.globl _setegid _setegid: moveq #47,d0 movl #100,a0 moveq #1,d1 movl 4(sp),a1 trap #9 bccs 1$ jmp cerror 1$: clrl d0 rts
以下を seteuid.s
の中に記述すること。
.globl _seteuid _seteuid: moveq #47,d0 movl #100,a0 moveq #0,d1 movl 4(sp),a1 trap #9 bccs 1$ jmp cerror 1$: clrl d0 rts
ファイル作成後、これを以下のようにアセンブルする。
$
as seteuid.s
$
as setegid.s
その結果、seteuid.o
と setegid.o
が作成される。
次に、SambaのMakefileにて、DNIXセクションの中のLIBSM行にそれらを加える。 LIBSM行は、以下のものに多少似た形になるだろう。
LIBSM = setegid.o seteuid.o -ln
次に、includes.h
の DNIX セクションから
#define NO_EID
の行を削除する。
Red Hat Linuxのいくつかのバージョンでは、既定値を指定してインストールする間に、
以下のようなエントリを /etc/hosts
に追加する。
127.0.0.1 loopback "hostname"."domainname"
これは Samba にループバックインタフェースへループバックすることを引き起こす。 結果として、 Samba は他の PC と正常に通信することに失敗する。 ひいてはマスターブラウズリストの保有者とマスターブラウザー が誰なのか正常にネゴシエートすることも失敗するだろう。
修正措置: 127.0.0.1 で始まる行の中で "loopback" という語の後のエントリを削除する。
シーケンシャル先読みを無効にすると、相対的に高度なマルチプログラミング (多数の smbd プロセスや他の負荷との混合)、充分でない物理メモリ、またはより遅い ディスク技術がある場合に、Sambaの効率を著しく改善できる。 これらは AIX に高いウエイト値の原因となる。 シーケンシャル先読みを無効にすることは、またシステム上の他の負荷に対して反作用 を及ぼすことがあるため、他のアプリケーションへのインパクトを評価する必要がある。
IBMによって提供される既定値の利用が推奨される。しかし多数のウエイトタイム を経験した場合、以下のコマンドで先読みを無効にすることを試すこと。
AIX 5.1 とそれ以前: vmtune -r 0
AIX 5.2 とそれ以降の jfs ファイルシステム: ioo -o minpgahead=0
AIX 5.2 とそれ以降の jfs2 ファイルシステム: ioo -o j2_minPageReadAhead=0
もし、jfsとjfs2ファイルシステムが同一ホスト上に混合する場合、単純に 双方のiooコマンドを利用する。
Solaris上でSambaを稼働させて、F_SETLKW64/fcntlにまつわる問題を経験 している人たちがいる。 ビルトインのファイルロック機構はスケーラブルではなかった。 プロセスがファイルのロックを試行するループへ入り込むまで、効率が低下するだろう。 それは、ロックを試行し、失敗し、そして再び試行する。 ロックする試みは、許可が与えられる前に失敗する。 目に見える兆候は CPU を一握りのプロセスが占有することであり、もしもそれらが 信頼されるのであれば、F_SETLKW64 のループから抜け出せなくなるだろう。
このバグを修正するために必要な最新のパッチを Sun のサポートに確認すること。 Solaris 2.6 向けのパッチリビジョンは 105181-34 、 Solaris 8 向けは 108528-19 、 Solaris 9 向けは 112233-04 である。 パッチをインストールした後、 Samba を再び構成しリビルドすることを推奨する。
この件について報告した Joe Meslovich に感謝する。
Solaris 9 のnsswitchは、Winbind NSS モジュールの利用を拒絶する。 この振る舞いは、 112960-14 というSUNによるパッチにて修正されている。
Table of Contents
この章では、クライアント固有の情報について記述している。
もちろん対応している。Thursbyは、 DAVEという CIFS client/serverを提供している。これはWindows 95、Windows NT/200x/XPとSambaに対して、 互換性についてテストされている。これを書いている時点で、DAVEはバージョン 5.1である。 この製品についての情報はThursbyのWebサイトを参照してほしい。
ある種のUNIXといくつかの商用のものに対する、2つのAppleTalkの自由な実装を含む代替品が ある。これらの製品はMacintocth上で追加のサポートなしに、Macintoshユーザーにネイティブな ファイルサービスと印刷サービスを動かすことが出来る。2つの自由な実装は、 Netatalkと CAPである。 SambaがMicrosoft Windows ユーザーに対してサービスを提供するのに対し、それらの パッケージははMacのユーザーにサービスを提供する。これらのパッケージ、Sambaと Linux(と他のUNIXベースのシステム)についての詳細は、 http://www.eats.com/linux_mac_win.html. を参照のこと。
Macintoshの新しいバージョン (Mac OS X) はSambaが含まれる
基本的に以下の3つのコンポーネントが必要である:
The File and Print Client (IBM peer)
TCP/IP (Internet support)
The “NetBIOS over TCP/IP” driver (TCPBEUI)
Warpマニュアル中で説明されているblankシステム上に、ベースOSと共に 最初の2つを一緒にインストールする。もしもWarpがすでにインストールされて いるが、ネットワークサポートを使いたいならば、“System Setup” フォルダー中の“Selective Install for Networking”オブジェクトを 使うこと。
マニュアルに書いていない、オンラインのドキュメントにもほとんど
書いていない、“NetBIOS over TCP/IP”を追加する。
MPTS.EXE
を開始し、OKをクリックし、
をクリックし、
Protocols中の
をクリックする。
この行は次にCurrent Configurationに移動する。
この行を選択し、 をクリックし、
値を0から1に増やす。この設定を保存する。
もしも、Sambaサーバーがローカルサブネット上にない場合、
IBM Peer
に対するアップデートをダウンロードする
必要があるかもしれない。IBM OS/2 Warp Webページを参照のこと。
この節では、OS/2 Warp 3(Connectでない)、OS/2 1.2、1.3、 あるいは2.xの設定について記述する。
ftp://ftp.microsoft.com/BusSys/Clients/LANMAN.OS2/にある、
OS/2用の、自由に使えるMicrosoft LAN Manager 2.2cクライアントを使うことが
できる。nutshellで、OS/2 ブートパーティションのrootディレクトリ中にある
\OS2VER
ファイルを編集し、クライアントインストールの
前に、以下の行を追加する:
20=setup.exe 20=netwksta.sys 20=netvdd.sys
また、バグだらけなので同梱されているNE2000ドライバーを使ってはならない。 その代わりに、 ftp://ftp.cdrom.com/pub/os2/network/ndis/からNE2000かNS2000 ドライバーをダウンロードする。
誰でもが書き込み可能な、[PRINTDRV]
という
共有を作成する。そこに使用しているOS/2ドライバーファイルをコピーする。
.EA_
ファイルは引き続き分離しなければならないので、
オリジナルのインストールファイルを使う必要があり、OS/2システムからの
インストールされたドライバーをコピーしてはいけない。
そのプリンターに対し、NTドライバーを最初にインストールする。次に、
使用しているsmb.conf
に、パラメーター
os2 driver map
を追加する。次に、filename
で指定されるファイル中に、
以下のようにNTドライバー名をOS/2ドライバー名にマップするように記述する:
, e.g.,nt driver name
= os2 driver name
.device name
HP LaserJet 5L = LASERJET.HP LaserJet 5L
このファイル中にマップされた複数のドライバーを定義できる。
もしも、OS/2ドライバー名のみを指定し、デバイス名を指定しない場合、 ドライバーを最初にダウンロードするときには、実際にファイルをダウンロード するが、OS/2クライアントは、ドライバーが有効でないと表示する。2回目に ダウンロードするときには動く。これは、マッピングにデバイス名を追加する ことにより簡単に解決し、その後、最初のダウンロード要求で動くようになる。
もしもWindows for Workgroupsを使うのであれば、Microsoftから最新のTCP/IPスタックを 使う。古いTCP/IPスタックにはたくさんのバグがある。
MicrosoftはそのTCP/IP 32ビットVxDドライバーの増分更新を公開している。最新のリリースは、
ftp.microsoft.comの/Softlib/MSLFILES/TCP32B.EXE
にある。そこには
修正された問題について説明してあるupdate.txtがある。そこには更新された
WINSOCK.DLL
, TELNET.EXE
, WSOCK.386
,
VNBT.386
, WSTCP.386
, TRACERT.EXE
,
NETSTAT.EXE
,NBTSTAT.EXE
ファイルがある。
このパッチについての詳細情報は、 Knowledge Base article 99891 にある。
Windows for Workgroupsは、パスワード管理の出来が悪い。UNIXマシンかPCのどちらかで パスワードを変更した時、最も安全にするにはWindowsディレクトリ中の.pwlファイルを 削除することである。PCはそのファイルが見つからないと警告を出すが、間もなく、 新しいパスワードが入力できるようになる。
もしもこれをしないと、新しいものを入れても、Windows for Workgroupsは古いパスワードを 記憶してそれを使うようになるかもしれない。
しばしばWindows for Workgroupsはダイアログボックス中で入力したパスワードを完全に無視する。
WFS 3.11ディスクセットの最後のディスク(8枚目)に、admincfg.exe
という
プログラムがある。これをインストールするためには、
EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXE
と入力する。
次に、Program Managerの 経由でアイコンを
追加する。このプログラムは、どのようにWFWがパスワードを扱うか、パスワードのキャッシュを
無効にするなどを、security = user用に制御する。
Windows for Workgroupsはサーバーに送る前にパスワードをすべて大文字にする。しかし、
UNIXのパスワードは大文字小文字を区別する。チェックするときにどの文字をSambaが大文字と
して試すべきかを指定するための、password level上の
smb.conf
情報をチェックすること。
印刷キューの通知をサポートするために、Windows for Workgroups下でTCP/IPを 既定値のプロトコルとして使う事が必要である。もしもNetBEUIを既定値のままにすると、 あるシステム上では印刷キューの通知がうまくいかない。これはおそらく Windows for Workgroupsのバグであろう。
Windows 95 OEM SR2を使う場合、以下のアップデートはSambaを使う時に推奨される。 処理速度の改善中で説明した変更は、アップデートを インストールした後に影響するだろう。
ここで説明しているものよりもたくさんのアップデートがある。Windows 95の特定のバージョン 用に現在用意されているアップデートについて、MicrosoftのWebサイトを参照すること。
Kernel Update: KRNLUPD.EXE |
Ping Fix: PINGUPD.EXE |
RPC Update: RPCRTUPD.EXE |
TCP/IP Update: VIPUPD.EXE |
Redirector Update: VRDRUPD.EXE |
また、もしもMS Outlookを使っている場合、
OLEUPD.EXE
の修正をインストールする事が望ましい。この修正は、
Outlookを終了する時に長い時間かかっていることを改善するかもしれず、ネットワーク
コンピュータサービスにアクセスする時に目に見える改善がわかるかもしれない。
Windows 2000 SP2には数多くの不満な点があり、その1つは、Windowsドメイン中で Windows 2000 SP2クライアントに対してユーザープロファイルをホスティングするために、 Sambaサーバーを使う時にのみ現れる。これは、Sambaがドメインのメンバーであることを 仮定するが、もしもそうでない場合にたぶんおそらく現れるだろう。
Windows 2000 SP2クライアントに正しくプロファイルを提供するために(PDCとして
動作していない場合)、Sambaはローミングプロファイルを格納するファイル共有のために、
nt acl support = noを設定しなければならない。
もしもこれが行われていない場合、Windows 2000 SP2クライアントはプロファイルにアクセス
出来ないと、警告を出し(Access Denied)、その複数のコピーをディスク上に作成する
(DOMAIN.user.001,DOMAIN.user.002など)。このオプションについては、smb.conf
の
マニュアルページを参照のこと。また、nt acl support
パラメーターが、Samba 2.2.2より前のリリースでは、正式にはグローバルパラメーターであった
事にも注意。
以下の例は、最低限のプロファイル共有を提供する。
このバグの原因は、Windows 200x SP2クライアントが、SambaサーバーのSIDを含むプロファイルの ためのセキュリティディスクリプタをコピーする事によるものである。クライアントは、 Samba\userのSIDを比較し、DOMAIN\userに割り当てられたものと違うと理解する。そのため、 access deniedメッセージが表示される。
nt acl supportが無効になっている場合、SambaはWindows 200x クライアントに、プロファイルに対する既定値のACLを設定させる、 QuerySecurityDescriptor trans2呼び出しのレスポンスを送信する。この既定値の ACLは以下を含む:
DOMAIN\user “フルコントロール”>
このバグはドメインユーザー用に、Sambaホスト上でアカウントを作成するために、 Winbindを使う時には起こらない。
もしも、Windows NT 3.1ワークステーションでルータ越しに通信をする時に 問題が起きたならば、 this\ Microsoft Knowledge Base article:を読むこと。
Table of Contents
SamvaサーバーはクライアントとTCP通信を使用しているため、パフォーマンスを上げるには 同じプロトコルを使用しているプログラムと比べてみるべきである。最も簡単に入手できる TCPを使用したファイル転送プログラムは、FTPもしくは他のTCPベースのSMBサーバーである。
もしNTやWindows Workgroups serverに対して実験してみたいなら、クライアントかサーバーの TCP以外は無効にする必要がある。 そうしないとNetBEUIのようなまったく違うプロトコルが使われ、比較は意味がない。
通常、SambaプラットフォームがFTPと同じぐらいの理論上の転送速度で動作することが解る だろう。速度はそのシステムの環境次第だが、NFSよりかは相当早い。
何人かは、SambaとNovell、NFS又はWindows NTとの間での比較を行った。そのうちの いくつかの場合は、Sambaの動作は一番よく、ほかの場合は一番悪かった。最も 大きな要素は、Samba対他のシステムではなく、種々のシステムで使用しているハードウェアと ドライバーであると推測している。同じようなハードウェアで、Sambahaは他のシステムと、 速度の点において競合できうる。
いくつかのオプションは、SambaのようなTCPベースのサーバーのパフォーマンスに 大きな影響を与える。
Sambaが使うソケットオプションは、-O
をコマンド行に指定するか、
smb.conf
ファイルに記述できる。
smb.conf
のマニュアルページのsocket optionsに、
どのように記述するか、推奨は何かがが書いてある。
ソケットオプションを正しく設定すれば大きくパフォーマンスを改善できるが、 間違って設定すると同じくらいパフォーマンスが悪くなる。正しい設定は、 使用するネットワークにとても依存する。
TCP_NODELAYは多くのネットワークにおいて、単独で大きな違いを引き起こす。 多くの人々がsocket options = TCP_NODELAYを 追加することで、Sambaのreadパフォーマンスを2倍にしたと報告している。 MicrosoftのTCP/IPスタックがTCP ACKを送るのが遅いためだというのが一番良い説明だろう。
socket options = SO_RCVBUF=8192
をsmb.confの中に書き込む
ことで、Sambaのループバックアダプター(IP Address 127.0.0.1)のパフォーマンスが
ひどく下がるという報告がある。socket options
を設定する前に、
サーバー上で定量的に計測することを強く推奨する。
read sizeオプションは、ディスクのR/WとネットワークのR/Wの 同時動作に影響する。 いくつかのSMBコマンド(currently SMBwrite, SMBwriteXとSMBreadbraw)で転送されている データ量がこの値より大きかったとき、サーバーはネットワークからそのパケットを受け取る前に データを書き込む。もしくは、SMBreadrawコマンドの場合、全てのデータをディスクから 読む前にネットワークに書き込む。
この並列動作は、ディスクアクセスとネットワークアクセスがほぼ同じ速度の場合に 最も効果があり、どちらか片方がとても早い場合にはあまり効果がない。
既定値は16384である。最適値を決めるために多少試験してみたが、最適値はシステム間で非常に 大きく違うようである。65536以上の値には意味が無く、不必要にメモリを割り当ててしまう。
起動時にクライアントとサーバーとの間で、ほぼすべてのコマンドサイズを制限する、
maximum transmit
値の調停を行う。
sambaが調停する最大値をsmb.conf
にmax xmit
オプションを使うことで設定できる。
これはSambaが受け取るSMBリクエストの最大値であり、クライアントが受け取る
最大値ではない。クライアントのmaximum受信サイズはクライアントからSambaに
送られ、Sambaはその値を信頼する。
既定値では65536バイトに設定されているが、より小さい値の方がよいという場合もありうる。 2048より小さい値にすると、重大な問題を引き起こす可能性がある。殆どの場合、 既定値が最適である。
debug levelとして設定できるログレベルを2より大きくすると、 大幅にパフォーマンスが低下する。 これはサーバーが各操作後ににログをフラッシュし、それがとても時間がかかるためである。
read raw操作は、最適化された、レイテンシの小さい、 ファイル読み取り操作の為に設計されている。サーバーはそれをサポートしなくてもよいが、 Sambaはread rawサポートをオプションとしていて、 規定値では有効になっている。
ある場合、クライアントはread rawをうまく扱えず、 従来の読み取り操作を使うよりも、それを使うことで実際にはパフォーマンスが落ちる こととなり、そのため、read raw = noを 試して、ネットワーク上で何が起きるかを観察しても良い。それはパフォーマンスを 下げるか上げるか、あるいは何も起きないかもしれない。テストすることで真実が わかる。
write raw操作は、最適化された、レイテンシの小さい、 ファイル読み取り操作の為に設計されている。サーバーはそれをサポートしなくてもよいが、 Sambaはread rawサポートをオプションとしていて、 規定値では有効になっている。
多くの場合、write rawをパラメーターを変更しようとした場合、 変更すると通常よりも速度が遅くなる。
ログインが遅い場合は、多くの場合パスワードチェックのためである。 最も小さい実用的なpassword levelは、これを改善する。
大抵の場合、スピードの問題はクライアントに原因がある。(Windows for Workgroupsのような) クライアントはたいていの場合、TCPパフォーマンスをより改善できる。 Sambaとその他のCIFSクライアント中の、 各種クライアントについての節をチェックすること。
あるユーザーがメーリングリストに次のように発言した。
私はGentooの上でSamba 2.2.8aを動かしています。 最近私はカーネルのバージョンを
linux-2.4.19-gentoo-r10
からlinux-2.4.20-wolk4.0s
に変更しました。すると、Sambaの パフォーマンスに問題が生じました。多くの人々はおそらく “普通のソース(kernel)に移行しろ!”」と言うでしょう。 もちろん私は試しましたが、上手くいきませんでした。 私は100MBのLANと2台のコンピュータ(LinuxとWindows2000)を使っています。 LinuxサーバーでDivxファイルの入ったフォルダーを共有し、クライアント(Windows2000)で LAN経由で再生していました。2.4.19カーネルにする前は全てが上手く動いていましたが、 現在では動画は固まって止まってしまいます。サーバーからWindowsへファイルを移動させようと しましたが、それもとても遅いです。
それに対してこのような返答があった。
我々のSambaPDCサーバーは、3年間の間問題なく500以上のユーザー[Windows NT/XP]で3TBのデータを
ホスティングしていました。現在ではすべての共有がとても遅いです。親プロセスのsmbdは
継続してプロセスを起動していて、(通常なら平均で250なのに)1600以上のSMDBプロセスが
起動しています。これによってSUN E3500が2回壊れています。
幾たびもの調査の後、rm /var/locks/*.tdb
を実行することにしました。
その結果、再び良好に動作しました。
質問:*.tdbファイルを最良の状態に保持する何らかの方法はあるので しょうか?あるいは、どのようにしたら、素早く破壊状態を検出できるのでしょうか?
答え: はい、nmdbの停止と起動のたびにtdbbackup
を
実行してください。
質問:さらに言及したいこととして、サービスのレイテンシは削除前より かなり遅くなったように見えます。最高速度を保持する良いアイデアはありませんか?
答え:はい、同じ質問が前にありました。
MYOB Premier操作とそのデータファイルへのアクセスにおいて、とても不可解な徴候を 経験したと、あるサイトは報告した。そのファイルへのいくつかの操作で40秒から45秒の 時間がかかった。
Windowsクライアント上でプリンターモニタープログラムを走らせたところ、この問題が発生した。 ログから、1秒ごとに休止状態が発生していることが分かりました。
モニターソフトウエアを止めたところ、ネットワーク速度が普通(早い状態に)戻りました。 再びモニターソフトウエアを起動させたところ、再び遅くなりました。 プリンターはCanon LBP-810で and the relevant task wassomething like CAPON (not sure on spelling). モニターソフトウエアは、クライアントが印刷中、"印刷中"を表示している。
Windowsのクリーンインストールと、他のソフトを何度も段階的にインストールすることによって、 発見した。
この話の教訓:すべてをチェックしなさい(他のソフトウェアも含めて)!
Table of Contents
現在に至るまで、ACLのような、いくつかの高度な機能を含む、 OpenLDAP™の簡単な設定について議論してきた。 しかし、ネットワーク上の通信が引き続き平文であるという現状には対応しない。 これが、Transport Layer Security (TLS)が導入された 理由である。
OpenLDAP™クライアントとサーバーは、 RFC 2830(訳注:現在は RFC 4513が最新) Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. による、完全性と機密性を提供するため、Transport Layer Security (TLS)を使う 能力がある。
TLSはX.509証明書を使う。すべてのサーバーは有効な証明書を持つ必要があるが、 クライアント証明書はあってもなくてもよい。ここではサーバー証明書のみを 議論の対象とする。
サーバー証明書のDNはサーバーの名前を指定するCN属性を使う必要があり、CNは、サーバーの、
完全に記述されたドメイン名(FQDN)を引き継ぐ必要がある。追加の別名と
ワイルドカードは、subjectAltName
証明書エクステンションに存在しても
よい。サーバー証明書の名前についてのより詳細については、
RFC2830にある。
これについては次の節で詳細に説明する。
適切な証明書を作成するために、固有の認証局(CA)を立てる必要がある。 [8] これは必要であり、そうすると、サーバー証明書に署名できる。
これに対しては、ほとんどのLinux® ディストリビューションに含まれているOpenSSL [9] を使うことになる。
TLSは多くの種類のサーバーによって使われるが、その手続きは、 [10] ここで説明されていて、OpenLDAP に特化している。
以下の例におけるCommon Name (CN)は、使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない。
最初に認証局(CA)を生成する必要がある:
root#
mkdir myCA
そのディレクトリに移動する:
root#
cd myCA
Now generate the CA:[11]
root#
/usr/share/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
.......................++++++
.............................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:NSW
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Abmas
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:ldap.abmas.biz
Email Address []:support@abmas.biz
注意すべき点がいくつかある。
サーバーの証明書に署名するのに必要なので、 パスワードを覚えておく必要がある。
Common Name (CN)は使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない。
次にサーバー証明書を生成する必要がある:
root#
openssl req -new -nodes -keyout newreq.pem -out newreq.pem
Generating a 1024 bit RSA private key
.............++++++
........................................................++++++
writing new private key to 'newreq.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:NSW
Locality Name (eg, city) []:Sydney
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Abmas
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:ldap.abmas.biz
Email Address []:support@abmas.biz
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
繰り返すが、ここでもいくつか注意すべき事がある。
パスワードを入力すべきではない。
Common Name (CN)は使用しているLDAPサーバーの 完全に記述されたドメイン名(FQDN)でなければならない。
次に新しい認証局(CA)の証明書に署名する:
root#
/usr/share/ssl/misc/CA.pl -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Mar 6 18:22:26 2005 EDT
Not After : Mar 6 18:22:26 2006 EDT
Subject:
countryName = AU
stateOrProvinceName = NSW
localityName = Sydney
organizationName = Abmas
organizationalUnitName = IT
commonName = ldap.abmas.biz
emailAddress = support@abmas.biz
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
F7:84:87:25:C4:E8:46:6D:0F:47:27:91:F0:16:E0:86:6A:EE:A3:CE
X509v3 Authority Key Identifier:
keyid:27:44:63:3A:CB:09:DC:B1:FF:32:CC:93:23:A4:F1:B4:D5:F0:7E:CC
DirName:/C=AU/ST=NSW/L=Sydney/O=Abmas/OU=IT/
CN=ldap.abmas.biz/emailAddress=support@abmas.biz
serial:00
Certificate is to be certified until Mar 6 18:22:26 2006 EDT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem
これでサーバー証明書の生成が完了する。
次に、正しい設定ディレクトリ中に証明書をコピーする必要があり、その後同時に改名して (利便性のために)、所有権を変更し、最後にアクセス許可を与える:
root#
cp demoCA/cacert.pem /etc/openldap/
root#
cp newcert.pem /etc/openldap/servercrt.pem
root#
cp newreq.pem /etc/openldap/serverkey.pem
root#
chown ldap.ldap /etc/openldap/*.pem
root#
chmod 640 /etc/openldap/cacert.pem;
root#
chmod 600 /etc/openldap/serverkey.pem
次に、これらのファイル位置情報を、以下のようにして、slapd.conf
の、database
定義の前のどこかに追加する必要がある:
TLSCertificateFile /etc/openldap/servercrt.pem
TLSCertificateKeyFile /etc/openldap/serverkey.pem
TLSCACertificateFile /etc/openldap/cacert.pem
以下は、ldap.conf
での定義である:
ldap.conf
TLS_CACERT /etc/openldap/cacert.pem
これですべてである。次にthe section called “評価”を行う。
root#
/etc/init.d/ldap restart
Stopping slapd: [ OK ]
Checking configuration files for slapd: config file testing succeeded
Starting slapd: [ OK ]
次に、ldapsearch
を使い、-ZZ
オプションを使って
[12]
匿名検索で評価する:
root#
ldapsearch -x -b "dc=ldap,dc=abmas,dc=biz" \
-H 'ldap://ldap.abmas.biz:389' -ZZ
以下のように、サーバーを再起動する前と結果は同じであるべきである:
root#
ldapsearch -x -b "dc=ldap,dc=abmas,dc=biz" \
-H 'ldap://ldap.abmas.biz:389' -ZZ
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# abmas.biz
dn: dc=ldap,dc=abmas,dc=biz
objectClass: dcObject
objectClass: organization
o: Abmas
dc: abmas
# Manager, ldap.abmas.biz
dn: cn=Manager,dc=ldap,dc=abmas,dc=biz
objectClass: organizationalRole
cn: Manager
# ABMAS, abmas.biz
dn: sambaDomainName=ABMAS,dc=ldap,dc=abmas,dc=biz
sambaDomainName: ABMAS
sambaSID: S-1-5-21-238355452-1056757430-1592208922
sambaAlgorithmicRidBase: 1000
objectClass: sambaDomain
sambaNextUserRid: 67109862
sambaNextGroupRid: 67109863
何か問題が起きた場合は、the section called “トラブルシューティング”を読んでみてほしい。
TLSを設定しているときに最もよくあるエラーは、何回も説明したように、 the section called “サーバー証明書の生成”で入力したCommon Name (CN)が、 使用しているLDAPサーバーの、完全に記述されたドメイン名(FQDN)でないという ものである。
他のエラーとしては、ldapsearch
コマンドのどこかでタイプミスしたとか、
servercrt.pem
とcacert.pem
に間違ったアクセス
許可を設定しているかである。the section called “証明書のインストール”単位に
chmod 640
で設定すべきである。
それ以外は、ldapのログファイルを読むか、OpenLDAPメーリングリストに参加するのが最も良い方法 である。
[9] 固有の認証局(CA)を作ることの不都合な点は、商用のものがそうであるように、 証明書がクライアントによって自動的に認識されないということである。
[10] 一番確かなところからの情報は、 http://www.openssl.org/docs/HOWTO/ のmain OpenSSLサイトを参照のこと。
[11] Your CA.pl
or CA.sh
might not be
in the same location as mine is, you can find it by using the locate
command, i.e.,
locate CA.pl
. If the command complains about the database being too old, run
updatedb
as root to update it.
[12] man ldapsearch
を参照
IT業界におけるもっとも回答が難しい質問のひとつが「サポートとは何か 」である。この質問を受けた人々はイライラし、その回答を受けた人々も大 抵同じくらいイライラするだろう。
サポートにつきものであるもっともイライラする象徴的な状況は、Linux ユーザーが インターネットサービスプロバイダーに電話したときに(解決策を探そうと、問題に ついて耳を傾けるかわりに)「「ああ、Linuxですか。Linux はサポートして おりません。」」と、素っ気なく返答された場合だ。これは私が経験したこ とであり、似た状況はIT業界の至る所で起きている。あるビジネスにとってただ相 手にしたくない顧客がいくらか存在するということを私たちに知らせることをこの ような回答は意図している。私たちは拒否されたことに激しい痛みを感じるだろう。
サポートについて深く考える一つの方法は、状況のいかんにかかわらず、正しい回 答、正しい場所、正しいタイミングによって構成されるという見方をすることであ る。苦労、混乱、不便、生産性の低下、不確実性そして実在するリスクまたは知覚 リスクを取り除くことがサポートのすべてである。
ある事実が、オープンソースソフトウェアを採用する駆動力の一つになっている。 おそらく多くのITビジネスが提供しているサービスは、顧客の期待にそえられない か、その他の理由により十分でなかった。
ITユーザーまたは消費者が期待する最初の経験のときのニーズを満たす必要性を認 めて、この章では問題解決に関する不愉快な経験を避けるのに役立つ情報を提供す る。
オープンソースの分野ではサポートに2つの選択肢がある。無償サポートと有償(商 用)サポートである。
無償サポートは、友人、同僚、ユーザーグループ、メーリングリスト、対話的な ヘルプファシリティーから得られる。対話的なヘルプファシリティーの一例にユ ーザー同士での支援の場所を設けるIRC(Internet relay chat)チャネルがある。
Samba プロジェクトではSamba をデプロイする方法を議論するメーリング
リストを維持してきた。Samba メーリングリストへの参加申し込みについ
ての情報は、 Samba
ウェブサイト にある。無償で利用できる、ユーザーの貢献による
公共のメーリングリストのサポートは samba
リスト
と呼ばれている。リストへの email アドレスは
mail:samba@samba.org
である。Samba IRCチャネルについての情
報は Samba IRC
ウェブページにある。
一般的なルールとして、Samba チームメンバーに直接無償のサポートを求 めて連絡をするのはお粗末な作法である。Samba チームのアクティブなメ ンバーのほとんどは、要件を満たすことが立証された問題をサポートする ために大変長い時間働いている。Samba チームのメンバーは対価を受けと ることで、直接メールや電話でのサポートの連絡を受けている。何人かの Samba チームメンバーは、実際に有償の 専門的な Samba サポートを提供 している。
Samba のバグに遭遇した場合、大抵において解決するもっとも早い方法は レポートを投稿する ことである。すべてのレポートは責任あるコードメインテナーにアクショ ンを起こさせるためにメールされる。レポートがよく書かれていたり、そ の問題が深刻であれば、より早く扱われるだろう。一方では、メインテナ ーがレポートされたバグを再現できない場合は、却下されると思われる。 再現できるほど十分な情報を提供することはレポートする人の責任である。
無償サポートでは、要求された期限の中では解決策を提供できないことが あることを承知している。他方で問題が理解しにくく、問題を切り分ける たりひいては解決をするのに必要な経験に欠けているような場合がある。 そういう場合は有償サポートを購入することが賢明だろう。
Samba サイトにてありふれて見られるサービス指向の基本的なサポートが 以下の6つである。
ネットワーク設計の補助
スタッフトレーニング
Samba ネットワークの配置と導入の補助
Samba 設定の優先的な電話やメールによる補助
トラブルシューティングと診断の補助
品質が保証され、インストールする準備ができ ている (ready-to-install) Samba バイナリパッケージの提供
Samba の専門的なサポートを提供する会社についての情報は、Google 検索 や、Samba Support ウェブページでも入手できる。Samba チームへ商用サポ ートの提供を知らせた会社は、国別で整列されたリストに載せている。リ ストの記載について重複が認められているが、保証は提供されない。サポ ート会社の選定や会社とその従業員は要求されることを提供することが出 来るということに納得することは利用者次第である。
Samba チームのポリシーは、すべてのサポート会社を等しく扱うことと好 みを提示しないこと。結果として商用サポートを提供している Samba チー ムのメンバーもその他と一緒くたにされている。地元の会社から必要なサ ービスを得るように奨励する。オープンソースムーブメントはプロの団体 です。 だから、できることをして地元の企業が成功するのを助けて欲しい。
オープンソースソフトウェアのサポートはいかなる品質、費用、場所でも 得ることができる。世界中で180社以上が Samba のサポートを提供してい る。Samba がサポートされないソフトウェアという誤った信念に苦しむ理 由はない。 Samba はサポートされている。
UNIXの領域においては、 Domain Name System (DNS) と Dynamic Host Configuration Protocol (DHCP) と同じくらいたくさんの論争が起こる主題はない。 DNSとDHCPの特定の実装に賛成、反対する意見の一部は有効である。 There are few subjects in the UNIX world that might raise as much contention as Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP). Not all opinions held for or against particular implementations of DNS and DHCP are valid.
多くの情報技術を利用する人が、携帯性と利用の自由を要求する現代に、我々は生きている。 Microsoft Windows ユーザーは特に、使用しているノートPCをネットワークに繋げば、 “ちゃんと動く”事を期待している。
UNIX管理者はpoint。Microsoft Windowsの領域における多くの標準的な習慣が、セキュリティの 観点からは悪い習慣上で最も良い境界にある(???)。Microsoft Windows ネットワーク プロトコルは、ネットワーク上に、ワークステーションそれ自身を登録する機能を用意している。 Windows 2000のActive DirectoryはDNS名前空間に、UNIX管理者が困惑するような、エントリを 登録する。世界は変わってしまったのである! UNIX administrators have a point. Many of the normative practices in the Microsoft Windows world at best border on bad practice from a security perspective. Microsoft Windows networking protocols allow workstations to arbitrarily register themselves on a network. Windows 2000 Active Directory registers entries in the DNS namespace that are equally perplexing to UNIX administrators. Welcome to the new world!
この章の目的は、Microsoft Windows 2000 サーバー製品中でのものと互換性のある、動的サービスを 提供するために、Internet Software Consortium (ISC) のDNSとDHCPサーバーの設定をデモすること である。
この章では、DNSとDHCPサーバーの両方に対する、動く設定ファイルの例を提供する以上のものでは ない。例は、このドキュメント中のどこかで使われている設定例に一致するものを使う。
この章では、明示的にチュートリアルでも、全体として、この文書の意図と範囲を超えているので、 DNSとDHCPのリファレンスガイドの代替品を提供しない。DNSまたはDHCPについてのより詳細な 参考情報を知りたいのであれば、ISCのWebサイト http://www.isc.orgを参照のこと。 書籍として情報が欲しいのであれば、 オライリー のWebサイトに行って、DNSの本の情報を、また、 BIND9.NETというWebサイトを 見てみると良い。 書籍情報は以下の通り:
DNS and BIND, By Cricket Liu, Paul Albitz, ISBN: 1-56592-010-4(訳注:日本語訳あり)
DNS & Bind Cookbook, By Cricket Liu, ISBN: 0-596-00410-9
The DHCP Handbook (2nd Edition), By: Ralph Droms, Ted Lemon, ISBN 0-672-32327-3
DNSは、インターネットにとっては、生活における水のようなものである。ほとんどすべての 情報リソース(ホスト名)はDNSを通してそのIPアドレスに解決される。Windowsネットワークは DNSの複雑さを防ぐために、かなりいろいろな事をやっていたが、結局DNSの勝ちであった。 DNSの代わりとしてWindows Internet Name Service (WINS) がある。 NetBIOS networking over the TCP/IPプロトコルの悪い点は、情報技術ネットワークの 複雑さと規模が発展していく時に、管理できなくなる、平坦で階層構造のない名前空間の ような拡張性の問題が明らかとなっていることである。
WINSはMicrosoftによるRFC1001/1002 NetBIOS Name Service (NBNS)の実装である。これは、 NetBIOSクライアント(Microsoft Windowsマシンのような)に、マシンに与えられたIPアドレスと 一緒に管理者かユーザーが選べる任意のマシン名を解決することができる。WINSを使うと、 ネットワーククライアントマシンは、マシン名をそのIPアドレスに解決できる。
NetBIOSネットワークファミリの制限に対する代替のための要求は、最終的に、Microsoftが DNSとActive Directoryを使うように追い込んだ。Microsoftの新しい実装は、NetBIOS ネットワークにおいて、WINSが使われる方法と同様のやり方で、DNSを使うことを試みている。 WINSとMicrosoft DNSの両方は、動的な名前登録に頼っている。
Microsoft Windows クライアントは起動時にDNSサーバーに対して動的な名前登録を行うことが できる。その代わりに、ワークステーションのIPアドレスを割り当てるところにDNSが使われる 場面において、クライアントが、IPアドレスの貸出を受け取ったら直ちに、DHCPサーバーによって そのホスト名とIPアドレスを登録することが出来る。最後に、Microsoft DNSは、Microsoft WINS 経由でホスト名を解決できる。
以下の設定は、単純な、セキュリティを考慮していないDNSサーバーと、DNSの設定にあわせた 単純なDHCPサーバーの例を提示している。
DNS設定の例は、ネットワーク 192.168.1.0/25のIPアドレス範囲中のプライベート ネットワーク用である。プライベートなネットワークアドレス空間はRFC1918に 説明がある。
このネットワークは安全なファイアウォールの内側に位置していることを仮定している。 以下のファイルはISC BINDバージョン9用である。BINDは Berkeley Internet Name Daemonの略である。
マスター設定ファイル/etc/named.conf
は、この後使用する
すべての設定ファイルの位置を決める。このファイルの位置と名前は、OSの一部である
起動スクリプト内で指定されている。
# Quenya.Org の設定ファイル acl mynet { 192.168.1.0/24; 127.0.0.1; }; options { directory "/var/named"; listen-on-v6 { any; }; notify no; forward first; forwarders { 192.168.1.1; }; auth-nxdomain yes; multiple-cnames yes; listen-on { mynet; }; }; # The following three zone definitions do not need any modification. # The first one defines localhost while the second defines the # reverse lookup for localhost. The last zone "." is the # definition of the root name servers. zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; zone "." in { type hint; file "root.hint"; }; # You can insert further zone records for your own domains below. zone "quenya.org" { type master; file "/var/named/quenya.org.hosts"; allow-query { mynet; }; allow-transfer { mynet; }; allow-update { mynet; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/var/named/192.168.1.0.rev"; allow-query { mynet; }; allow-transfer { mynet; }; allow-update { mynet; }; };
以下のファイルはすべて/var/named
というディレクトリにある。
これは/var/named/localhost.zone
ファイルである:
$TTL 1W @ IN SOA @ root ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS @ IN A 127.0.0.1
/var/named/127.0.0.zone
ファイルである:
$TTL 1W @ IN SOA localhost. root.localhost. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS localhost. 1 IN PTR localhost.
/var/named/quenya.org.host
ファイルである:
$ORIGIN . $TTL 38400 ; 10 hours 40 minutes quenya.org IN SOA marvel.quenya.org. root.quenya.org. ( 2003021832 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS marvel.quenya.org. MX 10 mail.quenya.org. $ORIGIN quenya.org. frodo A 192.168.1.1 marvel A 192.168.1.2 ; mail CNAME marvel www CNAME marvel
/var/named/192.168.1.0.rev
ファイルである:
$ORIGIN . $TTL 38400 ; 10 hours 40 minutes 1.168.192.in-addr.arpa IN SOA marvel.quenya.org. root.quenya.org. ( 2003021824 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS marvel.quenya.org. $ORIGIN 1.168.192.in-addr.arpa. 1 PTR frodo.quenya.org. 2 PTR marvel.quenya.org.
ここで示された設定ファイルは完全に動くシステムからコピーしたものである。すべての
動的に登録されるエントリは削除されている。それらのファイルに対してはさらに、
BINDバージョン9が、.jnl
という拡張子を持つファイルである、
各動的登録ファイルを作成する。構成ファイルと作成された.jnl
ファイルを編集したり、不正に変更してはならない。
以下のファイルはISC DHCPサーバー バージョン3で使われる。ファイルは、
/etc/dhcpd.conf
にある:
ddns-updates on; ddns-domainname "quenya.org"; option ntp-servers 192.168.1.2; ddns-update-style ad-hoc; allow unknown-clients; default-lease-time 86400; max-lease-time 172800; option domain-name "quenya.org"; option domain-name-servers 192.168.1.2; option netbios-name-servers 192.168.1.2; option netbios-dd-server 192.168.1.2; option netbios-node-type 8; subnet 192.168.1.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.1.60 192.168.1.254; option subnet-mask 255.255.255.0; option routers 192.168.1.2; allow unknown-clients; }
この例では、192.168.1.1と192.168.1.59のIPアドレス範囲は固定IPアドレス
(よくhard-wired
と呼ばれる)のために予約されている。
192.168.1.60から192.168.1.254の間のアドレスは動的な割り当てに使われる。
Table of Contents
Version 3, 29 June 2007
Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The GNU General Public License is a free, copyleft license for software and other kinds of works.
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program—to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.
For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.
Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users’ freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and modification follow.
“This License” refers to version 3 of the GNU General Public License.
“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
A “covered work” means either the unmodified Program or a work based on the Program.
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.
You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
The work must carry prominent notices stating that you modified it, and giving a relevant date.
The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
Limiting the use for publicity purposes of names of licensors or authors of the material; or
Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.
A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the program’s name and a brief idea of what it does.
Copyright (C)year
name of author
This program 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 3 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. You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:
program
Copyright (C)year
name of author
This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w
’. This is free software, and you are welcome to redistribute it under certain conditions; type ‘show c
’ for details.
The hypothetical commands ‘show w
’ and
‘show c
’ should show the appropriate parts of
the General Public License. Of course, your program’s commands might be
different; for a GUI interface, you would use an “about box”.
You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see http://www.gnu.org/licenses/.
The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html.
A detailed list of permissions granted to users or groups with respect to file and network resource access. See “ファイル、ディレクトリと共有のアクセス制御”, for details.
A service unique to Microsoft Windows 200x servers that provides a centrally managed directory for management of user identities and computer objects, as well as the permissions each user or computer may be granted to access distributed network resources. ADS uses Kerberos-based authentication and LDAP over Kerberos for directory access.
The new name for SMB. Microsoft renamed the SMB protocol to CIFS during the Internet hype in the nineties. At about the time that the SMB protocol was renamed to CIFS, an additional dialect of the SMB protocol was in development. The need for the deployment of the NetBIOS layer was also removed, thus paving the way for use of the SMB protocol natively over TCP/IP (known as NetBIOS-less SMB or “naked” TCP transport).
A recent implementation of a high capability printing system for UNIX developed by http://www.easysw.com/. The design objective of CUPS was to provide a rich print processing system that has built-in intelligence capable of correctly rendering (processing) a file that is submitted for printing even if it was formatted for an entirely different printer.
The domain master browser maintains a list of all the servers that have announced their services within a given workgroup or NT domain. See “ワークグループのブラウジングの設定” for details.
A protocol by which computer hostnames may be resolved to the matching IP address/es. DNS is implemented by the Berkeley Internet Name Daemon. There exists a recent version of DNS that allows dynamic name registration by network clients or by a DHCP server. This recent protocol is known as dynamic DNS (DDNS).
A protocol that was based on the BOOTP protocol that may be used to dynamically assign an IP address, from a reserved pool of addresses, to a network client or device. Additionally, DHCP may assign all network configuration settings and may be used to register a computer name and its address with a dynamic DNS server.
An intermediate file format used by Microsoft Windows-based servers and clients. EMF files may be rendered into a page description language by a print processor.
Device-independent format for printing used by Microsoft Windows. It is quite similar to what PostScript is for UNIX. Printing jobs are first generated in GDI and then converted to a device-specific format. See “Windows上でのGDI、UNIX上でのPostScript” for details.
The UNIX system group identifier; on older systems, a 32-bit unsigned integer, and on newer systems an unsigned 64-bit integer. The GID is used in UNIX-like operating systems for all group-level access control.
An IETF standard for network printing. CUPS implements IPP.
The Kerberos authentication protocol makes use of security keys (also called a ticket) by which access to network resources is controlled. The issuing of Kerberos tickets is effected by a KDC.
Very simple network protocol invented by IBM and Microsoft. It is used to do NetBIOS over Ethernet with low overhead. NetBEUI is a nonroutable protocol.
NetBIOS is a simple application programming interface (API) invented in the 1980s that allows programs to send data to certain network names. NetBIOS is always run over another network protocol such as IPX/SPX, TCP/IP, or Logical Link Control (LLC). NetBIOS run over LLC is best known as NetBEUI (NetBIOS Extended User Interface a complete misnomer!).
Protocol for transporting NetBIOS frames over TCP/IP. Uses ports 137, 138, and 139. NetBT is a fully routable protocol.
The local master browser maintains a list of all servers that have announced themselves within a given workgroup or NT domain on a particular broadcast-isolated subnet. See “ワークグループのブラウジングの設定” for details.
A printer page description language that was developed by Hewlett-Packard and is in common use today.
A highly compressed document format, based on PostScript, used as a document distribution format that is supported by Web browsers as well as many applications. Adobe also distributes an application called “Acrobat,” which is a PDF reader.
A language for describing the layout and contents of a printed page. The best-known PDLs are Adobe PostScript and Hewlett-Packard PCL (Printer Control Language), both of which are used to control laser printers.
PPDs specify and control options supported by PostScript printers, such as duplexing, stapling, and DPI. See also “PostScriptとGhostscript”. PPD files can be read by printing applications to enable correct PostScript page layout for a particular PostScript printer.
RPCs are a means for executing network operations. The RPC protocol is independent of transport protocols. RPC does not try to implement any kind of reliability and the application that uses RPCs must be aware of the type of transport protocol underneath RPC. An RPC is like a programmatic jump subroutine over a network. RPCs used in the UNIX environment are specified in RFC 1050. RPC is a powerful technique for constructing distributed, client-server based applications. It is based on extending the notion of conventional, or local procedure calling, so that the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.
SMB was the original name of the protocol `spoken' by Samba. It was invented in the 1980s by IBM and adopted and extended further by Microsoft. Microsoft renamed the protocol to CIFS during the Internet hype in the 1990s.
The UNIX system user identifier; on older systems a 32-bit unsigned integer, and on newer systems, an unsigned 64-bit integer. The UID is used in UNIX-like operating systems for all user-level access control.
A syntax for specifying the location of network resources (such as file shares). The UNC syntax was developed in the early days of MS DOS 3.x and is used internally by the SMB protocol.