Linux の 302 (Mixed Environment) 試験対策: ファイル・サービス

混在環境でファイル共有を作成および構成する方法を学ぶ

システム管理者のための、LPIC (Linux Professional Institute Certification) の LPI-302 試験に備えるために、この記事では混在環境でファイル共有を作成および構成する方法を学びます。

Sean A. Walberg, Senior Network Engineer

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



2011年 6月 24日

この連載について

この連載は Linux システム管理タスクの学習に役立つだけでなく、LPIC-3 (Linux Professional Institute Certification レベル 3) 試験に備えるための教材にもなります。

連載の各記事についての説明とリンクについては、developerWorks の LPIC-3 ロードマップを参照してください。現在進行中のこのロードマップは、LPIC-3 試験の最新の目標 (2010年 11月) を反映しています。完成した記事はその都度ロードマップに追加されていきます。

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

  • ファイル共有を作成および構成する
  • ファイル・サービスの移行を計画する
  • 管理用の共有、IPC$ を隠す
  • ユーザーおよびグループがファイル共有を操作するためのスクリプトを作成する
  • ファイル共有関連のコマンドライン・ツールを使用する

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

前提条件

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

ファイル共有の作成

前回の記事で、Samba は smb.conf に構成されたセクションのうち、homesprinters、および global 以外のすべてのセクションを共有名として認識すると説明しました。共有では共有名に加えて、共有名とディスク上の場所とのマッピングが重要な情報となります。以下に、最も単純な形の有効な共有を示します。

[tmpdir]
path = /var/tmp

選択的な LPI-302 試験について

LPIC (Linux Professional Institute Certification) には、さまざまなレベルがあり、レベルが上がるにつれ、より深い知識と経験が必要になってくるという点で、他の多くの認定と似ています。LPI-302 試験は、LPIC レベル階層のレベル 3 に位置する選択的な Specialty 認定試験であり、Linux システム管理に関する高度な知識が求められます。

LPIC レベル 3 (LPIC-3) 認定を取得するには、2 つのレベル 1 試験 (101 と 102)、2 つのレベル 2 試験 (201 と 202)、そして LPIC-3 Core Exam (301) に合格しなければなりません。これらの試験に合格した後、LPI-302 などの選択的な Specialty 認定試験を受けることができます。

上記のコードは、Samba サーバー上の /var/tmp にマッピングされる tmpdir という名前の共有を定義しています。サーバーの名前が phoenix だとすると、ユーザーがこのファイル共有にアクセスするには、UNC (Universal Naming Convention) パス \\phoenix\tmpdir を使用することになります。けれども、このわずかな構成では役に立ちません。共有のデフォルト設定は読み取り専用なので、上記の共有は書き込み可能にはならないためです。

セキュリティー・パラメーターを使用する

Samba には、誰が、どこからアクセスできるかを制御するセキュリティー関連のパラメーターが多数あります。これらのパラメーターの多くは、Samba が UNIX ファイルのパーミッションを操作するためのものなので、この記事では取り上げません。代わりに、それよりも一般的ないくつかのパラメーターについて説明します。

SMB (Server Message Block) サーバー (Microsoft ネイティブの実装を含む) には、IPC$ と呼ばれる共有があります。これは、プロセス間通信の共有で、ネットワーク経由でソフトウェアの機能を実行するために使用されます。名前がドル記号 ($) で終わる共有は隠し共有とみなされます。この隠し共有は、サーバーがその存在をアドバータイズするとしても、Microsoft ネットワークのクライアントには表示されません。

Samba は、たとえ smb.conf 内には記述がないとしても、IPC$ 共有を作成します。smb.conf に共有を作成すれば、その共有へのアクセスを制御することができます。以下に、制限を設けた IPC$ 共有の一例を記載します。

[IPC$]
  hosts allow = 192.168.1.0/255.255.255.0
  browsable = no

皆さん独自のフィードを作成してください

新しい記事が追加された際、あるいは内容が更新された際に通知を受けられるように、RSS、Atom、または HTML によるカスタム・フィードを作成することができます。それには、developerWorks RSS フィードにアクセスしてください。対象のゾーンとしては「Linux」を選択し、情報の種類としては「記事」を選択して、キーワードには「Linux Professional Institute」と入力します。そして最後にフィードの種類を選択します。

上記のスニペットは IPC$ 共有を定義し、192.168.1.0 ネットワーク上のユーザーだけがアクセス可能なようにしています。さらに、この例では browsable 機能をオフに設定し、クライアントがこの共有を要求しても表示しないように Samba に指示しています。

以前は、アタッカーがターゲットを無視することを期待して、IPC$ のような機密性の高い共有については隠すというのが一般的な慣例でした。この慣例は、IPC$ 共有について言えば馬鹿げています。例えばサーバーに共有のリストを要求するには、IPC$ 共有に接続しないわけにはいきません。したがって、Samba のデバッグ情報とパケット・トレースを調べれば、この bowsable オプションには何の効果もないことがわかります。この話題をわざわざ取り上げた理由は、このことが LPI-302 の試験概要で言及されているためです。IPC$ 共有を隠そうとするよりは、接続できるホストを制限したほうが、遥かに効果があります。

ユーザーはユーザー名を使用せずに共有に接続することができます。この場合、ユーザーはゲストになります。デフォルトでは、ゲスト・ユーザーは共有にアクセスすることができませんが、共有レベルで guest ok = yes と設定することで、このアカウントを有効にすることができます。デフォルトのゲスト・ユーザーは nobody ですが、グローバル・パラメーター guest account を使用すれば、このユーザーを変更することができます。

シンボリック・リンクは、ファイルシステムの 2 つの領域を関連付けるために UNIX システムで広範に使用されます。例えば、ホーム・ディレクトリー内でシステム全体の一時ディレクトリーへのシンボリック・リンクを作成して、これをホーム・ディレクトリーの一部であるかのように使用することができます。Samba はこれらのシンボリック・リンクを辿るため、ユーザーをファイル共有外部の領域にアクセスさせてしまう可能性があります。このような事態を防ぎたいとしたら、共有で follow symlinks = no を指定してください。

共有にアクセス可能なユーザーを制限するには、valid users パラメーターを使用します。例えば、valid users = sean, jon, isaac とすると、この 3 人のユーザーだけに、このパラメーターが指定されている共有へのアクセスが許可されます。このパラメーターは、機密性の高い共有に対する追加の安全対策として、ファイル・レベルのアクセス許可と併せて使用することができます。

ホーム共有

ユーザーには、それぞれの個人ファイル用としてホーム・ディレクトリーを提供するのが通常です。ホーム・ディレクトリーは、UNIX パスワード・ファイルに設定されているユーザーごとに割り当てられます。Samba では、個々の構成セクションを入力しなくても、[homes] セクションを使用して簡単に任意の数のホーム・ディレクトリーをエクスポートすることができます。例えば、誰かが joe という名前の共有を要求するとします。すると、Samba は joe という名前で構成されている共有を探します。該当する共有が見つからない場合、今度はこの名前のユーザーを探します。ユーザーが見つかると、Samba はこの共有のテンプレートとして [homes] セクションの構成を使用します。

リスト 1 に典型的な [homes] セクションを記載します。

リスト 1. ユーザーのホーム共有のテンプレート
[homes]
 comment = Home Directories
 writable = yes
 browsable = yes
 valid users = %S

リスト 1 の構成では、以下のような内容になっています。

  • まず、homes セクションの構成を開始します。
  • コメントを指定します。このコメントは、ユーザーが該当するサーバー上の使用可能なファイル共有の詳細を調べる際に表示されます。
  • 共有を書き込み可能に設定し、ユーザーがそれぞれのホーム・ディレクトリーに対して変更を加えられるようにします。
  • ユーザーが共有のリストを参照するときに、共有が表示されるように指定します。つまり、ユーザーにはホームと、そのユーザーの名前が設定された共有の両方が表示されます。
  • この共有に接続できるユーザーを、この共有を所有しているユーザーに制限します。

リスト 1 で %S マクロが使用されていることに注目してください。このマクロは共有の名前に展開され、共有名とユーザー名は同じなので、valid users による制限は、共有の所有者のみがその共有を使用できるように設定されます。

以上の構成により、ユーザーが共有のリストを検索すると、常にホーム・ディレクトリーが表示され、そこに接続できるようになります。また、共有はユーザーの UNIX ホーム・ディレクトリーにマッピングされます。

ホーム共有に関するもう 1 つの興味深い点として、\\server\homes に直接接続すると、まるで \\server\username に接続したかのように、独自の共有にアクセスすることになります。これは、Samba チームが共有マシンのユーザーたちの助けとなるように、混乱を減らすために導入している追加機能です。

ユーザーとグループを追加するためのスクリプト

ユーザー・リストで Microsoft ネットワークのドメインを調べてみると、自分のサーバーに接続しているユーザーがそのサーバーのローカル UNIX アカウントを持っていない場合があります。この問題を回避する 1 つの方法は、ユーザーが接続した時点で Samba にそのユーザーのアカウントを自動的に作成させることです。それには、add user script パラメーターを使ってユーザー追加用のスクリプトと %u を指定します。%u マクロは当該ユーザーに展開されます。この方法では、useradd のようなシステム・ツールを使用することも、独自のスクリプトを作成することもできます。

グループにも、ユーザーの場合と同じような add group script パラメーターがあります。このパラメーターは、Microsoft ネットワークのツールを使用して Samba インスタンスを管理する際に使用します。また、add user to group やこれと同様の delete スクリプトも役に立つツールです。スクリプトにできるタスクを網羅したリストは、smb.conf の man ページにあります。

デーモンにオンデマンドでユーザーを作成させることが常に最善策であるとは限りません。Samba と Linux が共通のユーザー・データベースを共有できるように、winbind または LDAP (Lightweight Directory Access Protocol) ベースの認証メカニズムを使用するほうが賢明な場合もあります。

大/小文字の混在に対処する

Microsoft ネットワークの領域では、ファイル名またはディレクトリー名の大文字と小文字は区別されません。つまり、FILE、file、FiLe はすべて同じファイルを指すということです。けれども Linux では、大文字と小文字の区別は重要であり、この 3 つのファイルはそれぞれに異なります。したがって、Samba は Microsoft と Linux との間でのあらゆる競合が解決されるような方法で、この 2 つの領域をマッピングする方法を認識しておかなければなりません。この大/小文字の扱いの違いのマッピング・プロセスは、「名前のマングリング (name mangling)」(または「名前の変換」、「名前の短縮」など) と呼ばれるプロセスの一環です。

ファイル名の大/小文字に関するマングリングに影響を及ぼすパラメーターの数は限られています。そのうち最も重要なパラメーターは、case sensitive で、その値は yesno、または auto のいずれかです。case sensitive が yes に設定されていると、Samba はクライアントが要求したとおりに大文字、小文字を適用します。この設定が no になっている場合、Samba はディレクトリーで大/小文字の区別を無視して一致を探します。

大文字と小文字を区別する場合に問題となるのは、大/小文字が誤って設定されていると、アクセスできないファイルが出てくる可能性があることです。一例として、test という名前のファイルと TEST という名前のファイルが保存されているディレクトリーがあるとします。この場合、Samba が大/小文字を区別したアクセスを使用しなければ、この 2 つのファイルを区別することはできません。

このパラメーターはデフォルトで auto に設定されます。auto に設定されていると、クライアントが大/小文字を区別したアクセスをサポートするかどうかを示す、クライアントの拡張機能のフィールドを調べます。Windows ネットワークのクライアントはこの機能をサポートしないため、大文字と小文字を区別しません。

default casepreserve case は、互いに連動するパラメーターです。preserve caseyes に設定されている場合には、クライアントの設定が適用されます。preserve caseno に設定されている場合には、新しく作成されるファイルの大/小文字の区別は default case の値を使用して決定されます。

usershare を有効にする

ユーザーが smb.conf を変更しなくても、usershare という機能を使用すれば、独自の共有を作成することができます。管理者が usershare 機能を有効にすると、一般ユーザーはコマンドライン・ツールを使って任意のディレクトリーをエクスポートできるようになります。共有が不要になった場合には、ユーザーがその共有を削除することもできます。

usershare 機能を使用する際の最初のステップは、グローバル・レベルでこの機能を有効にすることです。リスト 2 に、smb.conf から usershare を有効にする部分を抜粋します。

リスト 2. usershare の有効化
[global]
  usershare path = /var/lib/samba/usershares
  usershare max shares = 5
  usershare prefix allow list = /home
  usershare prefix deny list = /var, /usr

リスト 2 で操作しているのは、[global] セクションです。まず、usershare path で、Samba がユーザー共有関連の構成に使用するためのディレクトリーを定義します。このディレクトリーにはいくつかの制約が課せられますが、それについては後で説明します。次に、ユーザー共有の最大数を設定します。最後の 2 つのパラメーターは、共有可能なディレクトリーを制限するためのものです。usershare prefix allow list は、すべての共有を指定のディレクトリーに制限するパラメーターで、この例では、共有するディレクトリーを /home の下にあるディレクトリーに制限しています。usershare prefix deny list はその反対の方法を採り、指定されたディレクトリーを除くすべてのディレクトリーを共有可能にします。

Samba がユーザー共有に設ける制約は他に 2 つあります。1 つは、共有を作成したユーザーに対し、usershare path を書き込み可能にして、そのディレクトリーにスティッキー・ビットをセットする (1000 または +t) ことです。もう 1 つの制約は、usershare owner onlyfalse に設定されていない限り、ユーザーは共有するディレクトリーを所有していなければならないことです。

ファイルのパーミッションに関する最初の制約は、usershare path を作成するときには注意が必要であることを意味します。ユーザー共有を usershares グループに属するユーザーに制限したいとしたら、以下のような一連のコマンドが必要になります。

# mkdir -p /var/lib/samba/usershares
# chown root:usershares /var/lib/samba/usershares
# chmod 1770 /var/lib/samba/usershares

最初のコマンドで、ディレクトリーおよび必要なすべての親ディレクトリーを作成します。次のコマンドではディレクトリーのユーザー所有権とグループ所有権をそれぞれ root、usershares に設定します。そして最後のコマンドで、ディレクトリーの所有者およびグループのパーミッションを rwx に設定して、その他すべてのユーザーに対してはアクセスを拒否し、スティッキー・ビットをセットします。したがって、このディレクトリーを使用できるのは、root ユーザーと usershares グループのメンバーだけです。さらに、スティッキー・ビットにより、ファイルを削除できるのはファイルの所有者に限られます。

共有のセットアップは、おそらくこの演習で最も難しい部分です。ユーザーは以下のコマンドを実行することができます。

net usershare add docs /home/me/Documents/ "My docs" Everyone:F

上記のコマンドは /home/me/Documents を、すべてのユーザーがフル・アクセス可能な docs という名前の共有としてエクスポートします。他に実行可能なコマンドとしては以下に挙げるものがあります。

  • net usershare list: ユーザーが作成したユーザー共有を一覧表示します。
  • net usershare info docs: docs 共有の構成を表示します。
  • net usershare delete docs: docs 共有を削除します。

コマンドライン・ツール

Samba には、複数のコマンドライン・ツールが用意されています。Samba のユーザーたちは、Samba が提供する libsmbclient を利用して、よく使われる SMB/CIFS (Common Internet File System) ユーティリティーを作成しています。

UNIX と Windows の顕著な違いの 1 つは、UNIX では大きな 1 つのファイルシステムを使用する一方、Windows では一連のドライブ・レターを使用することです。リモートの Windows 共有は、smbclient ユーティリティーを使用して FTP (File Transfer Protocol) 風のインターフェースで参照することができますが、アプリケーションに対して透過的にするためには、リモートの Windows 共有を他のファイルシステムと同じようにマウントできなければなりません。

Samba に用意されている smbmount というユーティリティーは、mount.cifs として再パッケージ化されていることがあります。このコマンドは直接呼び出すことも、あるいは mount コマンドから呼び出すこともできます。リスト 3 に、Linux システムでリモート CIFS 共有を通常のファイルシステムにマウントする方法を示します。

リスト 3. リモート CIFS 共有をマウントする
# mount -t cifs '\\192.168.1.134\docs' /mnt -o user=myuser
Password:
# mount
...
\\\\192.168.1.134\\docs on /mnt type cifs (rw)

最初のコマンドで、CIFS ファイルシステムを指定の UNC パスにマウントし、これを /mnt に配置します。これは UNC パスを別とすれば、標準の mount 呼び出しとほとんど変わりません。オプションを渡すには、-o オプションを使用します。ここで唯一必要となるオプションは、ユーザー名だけです。mount.cifs の man ページで、その他すべてのオプションについて概説しています。オプションには、パスワードとドメインを含めることができます。パスワードを指定しなければ、パスワードの入力を求めるプロンプトが出されます。最後に mount コマンドで、マウントされたファイルシステムを表示します。

この方法の代わりに使用できるコマンドとして、smbsh もあります。smbsh は標準的な UNIX の手段によってファイルシステムをマウントするのではなく、ファイルを要求するライブラリー呼び出しをインターセプトし、必要に応じて要求を CIFS 共有にリダイレクトします。このコマンドはファイルシステムをマウントする場合と比べ、それほどの信頼性がないことから、ほとんどのシステムにはもう付属していません。

ファイル共有を移行する

ファイル・サービスをあるサーバーから別のサーバーへと移した場合、ユーザーが新しいサーバーにアクセスしなければならないことを忘れてしまう可能性がありますが、Samba では、サーバーを別の名前に対して応答させることができます。例えば、ファイル共有を phoenix という名前のサーバーから fs2 という名前のサーバーに移した場合、phoenix に対する要求に fs2 が応答することができます。この場合には当然、phoenix が応答しないように、このサーバーをオフにするか、名前を変更しなければなりません。

サーバーに別名を追加するには、グローバル・パラメーター netbios aliases を使用します。Samba サーバーの名前を、サーバーの UNIX 名以外の名前に変更したい場合には、netbios name パラメーターを使用してください。

ファイルシステムのマウントに関してこれまで学んだコマンドは、サーバーを移行するための準備として、あるサーバーから別のサーバーへファイルをコピーする際にも役立ちます。また、rsync のような UNIX ユーティリティーを役立てるというのも一考です。


次回の予告

ファイル共有についての話題は、今回の記事で終わりです。次回は LPI-302 試験の目標 312.3 に備えるために、プリンター共有を作成および構成し、これらの共有に他のシステムからアクセスする方法を学びます。

参考文献

学ぶために

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

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

議論するために

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

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=681540
ArticleTitle=Linux の 302 (Mixed Environment) 試験対策: ファイル・サービス
publish-date=06242011