2005年度情報システム構成論第9回分散ファイルシステム西尾信彦 [email protected] 立命館大学情報理工学部情報システム学科ユビキタス環境研究室ユーザ情報を共有する場合の問題 • 複数のサーバ上でユーザ環境(個人用設定ファイル等)を同様に構築することが困難 • 必要なファイルをあちこちに分散したくない • 必要なファイルを統一的に扱いたい • 分散ファイルシステムを利用する NFS(Network File System) • Unix系OSでほぼ確実に実装されている分散ファイルシステム • バイナリ特化のディレクトリサービスと言えなくもない • Linux kernel 1.2のころからVersion2が実装されている • 歴史が古く、文献が豊富である各自のHomeとしてNFSを使う • 各自のHome(/home以下)をNFSに置くことで可能 • 複数のホストで同一ユーザディレクトリサービス (NISやLDAP)と同一NFSを利用することによって、複数のホストを同一の環境で利用することができる。 • 疑問点 – なぜ、同一ディレクトリサービスと同一NFSの組で利用する必要があるのか Unix系のファイル権限の基礎 • Unix系OSでは『ユーザID』によって所有者を見分けている。 • 『ユーザ名』によってではないつまり • ユーザ名とユーザIDのペアが同一のユーザ情報を利用してアクセスする必要がある • 同一ディレクトリサービスと同一ファイルシステムのペアを利用する必要がある NFSの特徴 • 古いバージョンでは2GBのファイルまでしか利用することができない • 2GB以上のファイルを利用する場合はLinux kernel 2.4.x と glibc version 2.2.x が必要 • 原則的にファイルアクセスの判断は – NISに管理されたユーザIDのみに頼っている – NISのドメインでは透明に統一的な扱いになるが – ユーザIDを詐称されないようなガードが必要 NFSの問題点 • 通信経路暗号化が存在しない – 通信内容が丸見えである • 接続ホスト認証機構がない – サーバは接続元アドレスを元に接続の可否を決定する (/etc/exports)ため、接続を許可しているネットワーク内にノートパソコンなどを持ち込まれ，ユーザIDを詐称されるとフルアクセスされてしまう危険性がある – また、ユーザ別に接続許可を設置することができない • 通信途中で回線切断などが起こると操作中のファイルが壊れる可能性がある • ネットワーク的に切断されているときは，キャッシュ以外は一切利用できない AFS(Andrew File System) • Andrew Project (CMU)の成果 • NFSにKerberos認証を付加し、個人認証機構と通信暗号化を付加したもの • 世界中で共通のルート/../をもつ – Multi-institutionalファイルシステム • kloginによる期限つきトークンの生成 • ファイル(ディレクトリ)操作を詳細に区別 – コピー，修正，削除を区別する • CMU -> Transarc -> IBM CFS(Coda File System ) • AFS2を基本として、モバイル環境に特化した分散ファイルシステム – CMUのSatiyaの研究グループによる成果 • ネットワークから一時的にクライアントが切断されても利用可能 – 以前利用されたファイルなどをキャッシュとして保持し、切断などでアクセスできない場合はキャッシュにアクセスする – 復旧時にはマージ処理を行う Windowsでのファイル共有 • Windows独自のファイル共有 – 右クリックからフォルダの共有 – SMBプロトコル • Windows以外とのファイル共有 – NFSクライアントを利用する • NFSをWindowsで利用する (SFU) • ユーザIDマッピングを行う必要がある – ほとんどの場合NFSクライアントについている – Sambaを利用する • Windowsのファイル共有と同等の方法(SMB)でファイルを共有するUNIX上の分散ファイルシステム • Unix系で利用可能なSMBインプリメントである Sambaが利用できる Windowsファイル共有用プロトコル • SMB – – – – ファイルが共有可能プリンタも共有可能下位のプロトコルとしてNetBIOSを使う MS-DOS時代のLAN Managerから利用されているプロトコル • CIFS – SMBを拡張し、TCP/IPベースでNetBIOSを利用する必要がない – 現在のSambaやWindowsで利用されているプロトコル Samba • SMB/CIFSのUNIX系インプリメンテーション • ほとんどすべてのUnix系OSでサポートされている – 公式サイト情報より Sun Solaris,Sun OS, HP-UX, IBM AIX, IBM MVS, SGI IRIX, NEC UX/4800,SCO UnixWare, Compaq Tru64 UNIX, Linux, FreeBSD, NetBSD, MachTen など他多数 • 認証にNIS、LDAPなどを利用することができる Sambaの問題点 • セキュリティ的に脆弱 – 通信経路の暗号化がない – 構造上、Windowsが提供しているのと同程度のセキュリティしか確保できない – ユーザ名・パスワードなどの送信時に暗号化されないため、平文で流れてしまう。 WebDAV （Web-based Distributed Authoring and Versioning) • Webアクセス(HTTP)を拡張して、閲覧だけではなくファイル操作(書き込み、削除、変更)を可能にしたもの • HTTP(80 port)のみ公開することで利用できるため、ファイアウォール等の設定が安易 • 通信経路の暗号化などは、既存のWeb技術を利用することによって可能(SSL等) • HTTPを利用するため、OSやサーバ実体に依存しない P2P(Peer to Peer) • 最近(いろいろと)騒がれている分散ファイルサービス • 二つのノード間で直接ファイルをやり取りする P2Pの形式比較 • 中央サーバが接続しているノードとその提供ファイルのリストを管理する方式 (Napstar方式) – 利用者管理が安易 – 不正ファイルなどを監視することが可能 – 中央サーバが停止すると全体が停止する • 不特定多数のノードがバケツリレー方式で提供ファイルリストのマージやファイル送信を行う方式 (Gnutella/FreeNetなど) – どこかのノードが停止しても、システム全体が停止することはない(別ノード経由で利用することができる) – 不正ファイルなどが提供されていても監視することが困難 – 利用者管理は困難分散ファイルシステムまとめ • 複数のホストで同一ファイルシステムを扱う – NFS,AFS,CFSなど • 異なるOSや実装上で統一的にファイルを扱う – NFS,AFS,CFS,Samba,WebDAV,P2P • 分散しているファイルを統一的に扱う – P2P • 将来的には一部が停止しても全体が停止しない堅固な分散ファイルシステムが重要になる DNS DNS(Domain Name Service) • 分散配置型データベース、ディレクトリサービスの一種 • 一組織(いわゆるドメイン)単位で自身が管理する範囲の情報を持つサーバを設置・管理する • 自身のわからない部分に関しては他のサーバに問い合わせるということを繰り返して、目的の情報にたどり着く • 日本の大本はJPNIC – JPNICでWhoisを実行すれば（WhoisCGIがある）、登録されているドメイン⇔DNSサーバアドレスが検索できます DNSの仕組み DNSの動き DNSレコード • DNSが保持できる主要情報の種類 – SOAレコード(Start of Authority) • ゾーンの情報（更新頻度、シリアル番号など） – NSレコード • 対象ドメインのDNSサーバ名を指定する – PTRレコード • IPアドレスに対するホスト名を指定する – Aレコード（IPv6の場合AAAAレコード） • ホスト名に対応するIPアドレスを指定する – CNAMEレコード • ホスト名の別名（エイリアス）を指定する（できるだけ使わないほうがよい） – MXレコード • 対象ドメイン宛メールの受け取りサーバを指定する DNSの問題点 • プロトコル自身にセキュリティ機構が存在しない – DNS応答自身に信頼性がない – 悪意ある第三者がDNSの返答を偽ることができる – 返答を偽ることができた場合、正常な通信を別経路に引き込むことができる • システム的問題ではないが、非常に重要かつ被害が広範囲に及ぶにもかかわらず、管理が軽視されがち – DNSレコード操作には細心の注意を払うべき DynamicDNS • 動的に登録してあるホスト名⇔IPアドレスを変更することができる • 無料サービスが多数存在している – zive,ddo.jp など • 家庭で（ダイアルアップ環境で）サーバを立てるならば重要