サーバー - みる会図書館


検索対象: UNIX MAGAZINE 2003年7月号
81件見つかりました。

1. UNIX MAGAZINE 2003年7月号

USENIX Se ( u Sy 1P05 ⅳ m よりも高速である。 この手法には以下のような制限がある。ただし、 4 番目 の制限はこの論文では言及されていない。 1. 動的なバッフアのサイズを判断できないケー ある。 alloca() ( 割り当てられたバッファ ) と可変長の 配列である。 2. 関数スコープの変数の型を判断できない。 スが 2 つ UNIX MAGAZINE 2003.7 アクセス制御 使って、証明を組み立てることができる。 イアントはアプリケーション固有の論証可能なロジックを サーバーは ( 論証可能な ) 証明を調べるだけでよく、クラ るという問題は、サーバーからクライアントに移される。 する。これにより、 ( ーヨ殳に論証不可能な ) 命題を証明す アントは必要な命題の証明を送信してからサーバーに接続 アントから web サーバーに送信される。さらに、クライ ジックで構成されたすべてのファクト (fact) が、クライ ことを証明するために必要となる高次 (higher-order) ロ ステムでは、 Web ページへのアクセスが許可されている 柔軟かっ総合的な新しいシステムを提案している。このシ にもとづき、アプリケーションやポリシーに依存しない、 Bauer らは、 PCA (Proof Carrying Authorization ズムを相カ漣用したりすることか難しくなっている。 ため、より複雑なポリシーを表現したり、これらのメカニ 簡単な静的ポリシーしか実装していないことである。その のシステムの間題は、その多くがアプリケーション固有の まなアクセス制御システムか登場していると述べた。既存 など増え続ける個人清報矍するために、すでにさまざ ス制御システムを紹介した。 Bauer は、写真や医療カルテ Lujo Bauer は、 Web サービスのための新しいアクセ Edward Ⅵを Felten ( フ。リンストン : た学 ) Lujo Bauer 、 Michael A. Schneider 、 、 Veb のための当本的カつ柔軟なアクセスシステム 報告 : Michael Hohmuth はイできない。 4. 入れ子の ( 関数スコープの ) 関数を定義する関数の引数 3. イ隻された C ライプラリ関数を使用しない攻撃に弱い。 Bauer らはこのシステムを実装するにあたり、命題を 生成し、クライアントが送信した証明を検証するアプレッ トを使って、標準的な Web サーバーを告した。クライ アント側では、標準的な Web プラウザからすべてのサー ・トランザクションを隠蔽する HTTP プロキシーを 使う。このフロキシーは、サーバーから証明のチャレンジ を受け取ると、それに対する証明の作成を試みる。証明を 作成するために必要なファクトが足りない場合は、ファク ( 特殊な Web サーバー ) に照会する。 Bauer は、フロキシーはプラウサにプラグインとして組み込むこ ともできたが、プラウサへの依存を極力避けたかったのだ と語った。 Bauer は、システム性能の測定結果を提示した。性能 は、クライアント、ファクトサーバー、 Web サーバー間 のトランサクションの数に左右されるため、キャッシュ や孑則的な証明を用いて無駄なトランザクションを餘し た。クライアントは保護されている URL やファクトを キャッシュし、サーバーが実際にチャレンジを生成する 前に、サーバーのチャレンジ窈則と、そ窈隹測的な証明 を試みる。サーバーは証明された命題とクライアントが生 成した補助定理 (lemma) をキャッシュする。結果とし て、システム性能のオーバーヘッドは低くなる。 Bauer は、形式的なツールや方法論が実在することを 挙げ、講演を締めくくった。 Jonathan Shapiro ( ジョンズホプキンズ大学 : ) から、 キャッシングの観点からファクトが失効する仕組みに関す る質問カ咄された。 Bauer は、現在の時刻への参照を含め ることで、ファクトをタイムアウトさせることかできると 答えた。 別の参加者から、サーバーに未完成の証明をいつまでも 送り続ければ、 D 。 S 攻撃を仕掛けられるのではないかとい う質間が出された。 Bauer はその可能性を認めたが、従来 のシステムでも同様の攻撃力斗長告されており、サーバーが アクセス要求をみすから検証する必要がなくなった現在、 ある意味では以前よりも「やることは少なくなった」と 語った。もう 1 つの質間は、アクセスポリシーをサーバー に保存しなければならないのかというものだった。 Bauer は、そのはうカ ; 合はよいが、かならすしもそうする必要 はないと答えた。 173

2. UNIX MAGAZINE 2003年7月号

図 2 ワークグループ・モデルによるファイル・ と同しような機能をもち、 MacOS のファイルシステ ムに対応したグルーフ。サーバーの導入が進められた。 ・ Windows では、、ドメイン " という考え方が採用され、 ドメインのなかでアカウントやアクセス権などが一括管 クライアント 理されるようになった。さらに、 Windows サーバーと いうかたちで、やはり NFS サーバーと同様な機能をも ち、 NTFS に対応したグルーフ。サーバーの導入が進め クライアント られた。 クライアント これを読んで、、、なあんだ、 UNIX の NFS のような 角夬ガ去を実装しただけじゃないか " と思う人も多いだろ う。まさしくそのとおりで、それぞれの竟で、、 NFS 的 なもの " を作りだしただけであった。これ自体はあまりお もしろくない結末だが、ワークグループまたは Peer to クライアント クライアント Peer という考え方と名称だけは着実に根付いていった。 各クライアントのファイル資源を直接共有する インターネット上の P2P る。一方で、 PC がどんどん安価になり、さらに 1 台てイ可 2000 年以前にインターネットを使っていたユーサーの 十台ものシステムを収容できる Ethernet スイッチが一殳 大半は、電話回線とモデムを用いた PPP アクセスにより 化すると、数ート台規模のワークグループも珍しくなくなっ インターネットに接続していた。しかし、 2000 年を境に てきた。結果として、あちらこちらで混舌励ゞみられるよう 常日判妾続と広帯域イ始まり、この状況は一変した。 になった。 ます、フレツツ・ ISDN に代表されるダイヤノレアップ・ 当時、起きた問題は次の点にまとめられる。 アクセスの固定料金化により、実質的な常妾続が始まっ 資源発見のオーバーヘッド た。そして、 ADSL 、 CATV のケープルモデム、さらに どのシステムに必要なファイルがあるかが分かりにく は光ファイバー接続と次々に新たなサーピスが始まって い。少人数のグループなら、ファイルの所有者と妾話 いった。これと並行してインターネットへのアクセス帯 せば解決するし、各ューザーカイ吏っているシステムの名 域も 64Kbps から、数 Mbps (ADSL) 、さらには数ーを 前も檍えておけるだろう。しかし、大規模化すると、そ Mbps へと伸びていった。 のたびに相手を探しだして必要なファイルをみつけなけ このような環境では、当時の LAN で一般的だった れはならない。 100Mbps Ethernet (100Base (X) と同しとまではいか ・セキュリティ ないまでも、ファイル交換などはごく普通におこなえる。 単体での利用を前提として作られていた OS にワーク それにともなって、かってはワークグルーフでしかみられ グルーフ饑能が組み込まれたため、ユーザーごとのアク なかった P2P をインターネット上て使おうとする試みが セス権の設定などがうまくいかなくなった。 始まった。 このため、 Mac OS や Windows には大規模化にとも 伝説の Napster なう間題の鮹夬ガ去が次のように導入された。 インターネット上の P2P の先駆者は、いうまでもなく Napster であろう。 ・ Mac OS では、 UNIX などの一引殳的なマルチューサー OS が備えていたユーサー・アカウントやアクセス権の LAN におけるファイル共有を中心としたワークグルー プでは、大規模化とともに資源発見の問題カ俵面化した。 管理手法カり入れられた。その結果、 NFS サー 連載 . / UN Ⅸ Communication Notes— 0 52 UNIX MAGAZINE 2003.7

3. UNIX MAGAZINE 2003年7月号

UNIX Communication Notes 山口英 Peer to Peer モテル ネットワーク・サービスのモテル 一方、クライアント側ではサーバーほど強力なシステム は不要であり、そこそこの匪能さえあれはサービスカリ用 できる。また、クライアントか守るべきルールはサーバー インターネットでは、クライアント・サーバーモテルに との通信フロトコルだけで、クライアントて稼動する OS もとづくネットワーク・サービスが数多く考案されてきた。 やアプリケーションにいろいろな制約があるわけではな クライアント・サーバーモデルの本質は彳齬リ分担である。 い。このため、クライアントに求められる技術要件は、サ サーバーは特定の機能を提供する。一方、クライアントは ーバーの場合とくらべて比較自巒爰やかに考えてもよい。 ー殳にアプリケーション・プログラムとして構成さオ L 、ユ 見方を変えると、サーバーに重点的に投資をして強力な ーザー・インターフェイスを提供する。 1 つのサーバー システムを構成しておけは、クライアント・システムは は、ネットワークを介して複数のクライアントに共有され 多少非力でも十分にその役目を果たせることになる。これ る。このような彳難リ分担をネットワークを介しておこなう は、クライアントへの投資が少なかった日罸に、つまり、性 ことにより、ネットワーク上での分散型サービスが実現さ 能の高いシステムか高価で、個々のユーサーにはとうてい れる。 割り当てられなかった時代に適した考え方である。 1980 年代半は、に UNIX ワークステーションが登場し システム投資の考え方 て以来、長いあいだコンピュータは高価だった。ューサー クライアント・サーバーモデルのもう 1 つの側面は、シ 個人が独占的に UNIX ワークステーションを使えるよう ステム構築への投資の考え方を示していることだ。 な環境は、まさしく夢であった。和か所属する奈良先立斗 サーバーは複数のクライアントに共有されるため、一殳 ! 物支術大学院大学では、 1994 年から学生の受け入れを開 に潤沢な資源をもつ強力なシステムかイ吏われる。一例とし 始した。当時の・情報科学石形斗の学生募集用パンフレット て、メールサーバー (MTA) を考えてみよう。通常、メー を見ると、「各学生に 1 台すっ UNIX ワークステーショ ルサーバーは、その糸目織に属する全構成員によって共有さ ンを割り当てる環境を実現している」と書かれている。 れている。 1 人の利用者が送受信するメールの量はわすか のことからも分かるように、コンピュータか安価になった でも、全員ともな川ま、つねに大量のメールを処理する必 のはしつはも丘になってからである。このため、クライア 要がある。それには、ネットワークと広帯域で接続しな ント・サーバーモデルにもとづくサービス構成も長期にわ けれはならないし、高いシステム処理性能も求められる。 たってひろく使われていた。 受信したメールはスプールに蓄積するから、ディスク容量 容量と性能の劇的な向上 も必然的に大きくなる。つまり、高い性能をもつ強力なシ ステムをメールサーバーにするのは合ま軸勺な考え方といえ ところが、 1990 年代からはコンピュータの性能は劇的 る。このように、サーバーと呼はれるシステムは、資源が といってよいほど向上し、ユーサーも急増した。これにと 潤沢で生能の高いものを充てるのか普通であった。 もない、コンピュータ本体はもとより、メモリやディス 50 UNIX MAGAZINE 2003.7

4. UNIX MAGAZINE 2003年7月号

特集 LDAP でネームサービス 1 開始または停止させることができる。 管理サーバーの管理者 [root] : 【 Enter 】 [slapd—fire] : starting up server [slapd-fire] : [ 24 / Apr / 2003 : 03 : 28 : 53 + 0900 ] 057.0855 starting up [slapd—fire] : [ 24 / Apr / 2003 : 03 : 28 : 55 + 0900 ] a11 interfaces port 389 for LDAP requests Your new directory server has been started. Created new Directory Server Start S1apd Starting S1apd server configuration. Success SIapd Added Directory Server information t0 Configuration Server . Configuring Administration Server. Your parameters are now entered intO the Administration Server database , and the Administration Server wi11 be started . Changing ownership tO admin user root. Setting up Administration Server 工 nstance . Configuring Administration Tasks in Directory Server. Configuring G10ba1 Parameters in Directory Server. iP1anet—WebServer—Enterprise/6. OSPI B11 / 09 / 2001 13 : 59 : daemon iS running as super¯user [LS 1S1 ] http: //fire . localnet , port 3000 ready t0 accept requests startup: server started successfully 注意 : セキュリティ面では、 root とは異なるユーサー・アカウントを作成 し、そのユーサーの権限で管理サーバーを実↑」するはうがよい。 iPIanet—Directory/5.1 B2002. slapd started. Listening on Press ReturII tO continue . Go to /usr/sbin and type directoryserver startconsole tO begin your . これで新しいディレクトリ・サーバーか起動し、 LDAP リクエストを処理する準備か整った。 slapd サーノヾーか設 定・起動さオ、その情報か管理サーバーに保存された。 の点で、管理サーバーには管理タスクとグローバルなパ ラメータか書き込まれている。 インストールしたサーバーを管理するには、 /usr/sbin に移動して directoryserver startconsole" コマンドを 実行する。 以上の作業で、 LDAP サーバー本体 (slapd) と、 その 管理サーバー (ns-httpd) のプロセスか起動する。 作成されたディレクトリ・サーバーにアクセスし、 ⅱ乂 . 疋 された内容を確認しよう。ただし、この日点ではデータは まだ何も入っていない。 ディレクトリ・サーバーの構成 図 6 里コンソールへのログイン iPIane 00 れ 0 に一 第を朝ゴグイ、 . ユード 0 : 0 山「 / ミスワード : し , 44. アドミニストレー - シコン権 : 川地 0 許 308 へノレプ ( リ usr/sbin/directoryserver startconsole 起動すると、ログイン名を入力するウインドウか表示さ れる。そこで、 iPlanet ディレクトリ・サーバーの管理者 として指定したアカウント ( デフォルトは admin) でログ インする ( 図 6 ) 。管理サーバーは、しつはネ琪冓成時に指 定したポート番号で待ち受けている HTTP サーバーであ り、 Java で書かれた管理コンソール・プログラムからそこ にアクセスする。ただし、通常のプラウサでこの管理サー ログインしてください ディレクトリ・サーバーの管理に使用する管理コンソー ルは、次のコマンドて起測月一る。 115 UNIX MAGAZINE 2003.7

5. UNIX MAGAZINE 2003年7月号

特集 LDAP でネームサービス 1 このソフトウェアをスタンドアローンのサーバーにインス トールする場合、またはこのサーバーを設定ディレクト リ・サーバーにしたい場合は Enter を入力する。 このソフトウェアを既存の iPlanet 設定ディレクトリ・ サーバーに登録するか ? [NO] : 【 Enter 】 If you already have a directory server you want tO use tO store your data, such as user and group information, answer Yes tO the foIIowing question. You will be prompted for the host , port, suffix, and bind DN to use for that directory server. If you want this directory server tO store your data, answer NO . DO you want tO use another directory tO store your data? [NO] : ューザーやグルーフ。の情報などのデータを保存するための ディレクトリ・サーバーがすでに不力している場合は、 Yes と入力したうえて後続の質問に答える。既存のサーバーに ついて、ホスト名、ポート番号と接尾子、そのディレクト リ・サーバーを使用するためのバインド DN の入力を求 められる。 このサーバーにデータを保存したい場合には No と入力 する。 データを別のディレクトリ・サーバーに保存するか ? [ N 司 : 【 Enter 】 The standard directory server network port number is 389. However, if you are not logged as the superuser , or port 389 is in use , the default value wiII be a random unused port number greater than 1024. If you want tO use port 389 , make sure that you are logged in as the superuser , that port 389 is not in use , and that you run the admin server as the superuser. Directory server network port [ 389 ] : 標準的なディレクトリ・サーバーのポート番号は 389 で ある。ただし、スーパーユーザー (root) としてログイン していないか、 389 番ポートがすでに使用されている場 合は、 1024 番より大きい値か乱数で生成され、デフォル ト値として提示される。 389 番ポートを使いたいのなら、 root としてログインしていること、 389 番ポートが使用 されていないこと、管理サーバーを root で実行している ことを不裔忍する。 ディレクトリ・サーバーのポート番号 [ 389 ] : 【 Enter 】 Each instance Of directory server requires a unique identifier. Press Enter tO accept the default , or type in another name and press Enter . Directory server identifier [fire] 各ディレクトリ・サーバーの識別名は、ユニークでなけれ ばならない。デフォルトの指定でよい場合は Enter を、変 更したい場合は名前を言当してから Enter を入力する。 ディレクトリ・サーバーの識別名 [fire] : 【 Enter 】 PIease enter the administrator ID for the iP1anet configuration directory server. This is the ID typically used t0 10g in t0 the 112 console . You wi11 also be prompted for the password. UNIX MAGAZINE 2003.7

6. UNIX MAGAZINE 2003年7月号

特集 LDAP でネームサービス 図 2 DIT と DN cn = 長原宏治 ou = 出版部 1 ルート 0 = アスキー ou = 営業部 ロ RDN DN は cn = 山田太郎 DN は cn = 山田太郎、 ou = 出版部、 0 = アスキー cn = 長原宏治、 ou = 出版部、 0 = アスキー Solaris 9 に付属の iDS 5.1 では、 1 台のサーバーから 複数のサーバーにデータを複製するシングルマスター構成 ( 図 3 ) だけではなく、任意の台数のサーバーをマスターと して相互にデータを複製しあうマルチマスター構成をとる こともできる ( 図 4 ) 。 参照は、あるサーバーに対して検索がおこなわれたとき に、その情報をもっ別のサーバーと検索先の DN を返す 機能である。見方を変えれは、複数のサーバーが f 尉寺して いる情報を、参照を用いて 1 つの DIT にまとめることが できる機能ともいえる ( 図 5 ) 。また、同じサーバー内で 1 つのエントリに別の名前を付ける、、別名 (alias)" の機能 もある。 国際化機能 る。同様に phonetic タグを用いて、発音表現 ( 読み ) cn;lang-ja に日本語表現を保存するようなことができ できる。たとえば、 cn ( 共通名 ) に英語表現を保存し、 属性に言語タグを付け、されている言言重別を指定 言語タグ されている。 属性値や DN を表現する文字セットは UTF-8 と規定 ・コード表現は UTF-8 いる。多言語対応の機能には次のようなものがある。 LDAP では、多言言、の対応が規格として考慮されて 106 を明示することもできる。 バイナリ値 属性値がバイナリや 8 ピット文字コードの場合には、 Base64 でエンコードしてやりとりすることか規定され ている。 以 - E 、 LDAP の機能の概要を説明してきたが、 X. 500 から派生しただけあって、汎用的なディレクトリ・サービ スとしての f±様がきっちりと決められている。 LDAP は、 うまく活用すれは応用範囲がきわめて広い。普及はアプリ ケーションしだいだろうが、これはど強力な機能が So- laris に組み込まれたのはたいへん魅力的である。 iDS のセットアップ Solaris 9 には iDS 5.1 が付属しているが、初其伏態で はパッケージがインストールされているだけなので、ネノ月 構成作業をおこなう必要がある。 この作業では、ディレクトリのべースエントリ ( そのサ ーバーで管理するヨ造の根となるエントリ ) と、その下 に属するデータをオ褓内するデータベースなどを作成する。 また、ディレクトリ・サーバー本体だけではなく、 GUI を用いた管理イ′ド業のための管理サーバーのセットアップも 同時におこなう。管理サーバーは、複数の iDS サーノヾー を管理することもできるが、今回は単一のサーバーを構成 UNIX MAGAZINE 2003.7

7. UNIX MAGAZINE 2003年7月号

連載 /Cyber Kansai Project 図 1 システムの概要 ク ワ ッ ネ MBS 本社 ( 茶屋町 ) ライブ 二工ンコーダ NTTSmC( 堂島 ) 映像・音声処理システム 線 声回 用 像 送 旧 v6 インターネット 甲子園球場 ストリーミング 旧 v4 インターネット 一 ~ オンデマンド 制作システム サ イ ア 旧 v6 インターネット 旧 v4 インターネット HTML 制作システム Web サー 図 2 、Ⅵみ、システムの冓成 インターネット ( 旧 v6 ) 旧 v6 Chamomile インターネット ( 旧 v4 ) レイヤ 4 ス、、 旧 v4 旧 v6 コンテンツ用 Web サーバー Web サーバー Web サー/ ヾー Web サーバー Web サーバー NFS サーバー MBS 本社へ 4 台の Web サー ーを用いて負荷分散をおこない では、 ました。各サーバーのコンテンツは、 NFS を用いて同期 させています。 Web サーバーの構成は一ド記のとおりです。 ・ CPU : Xeon 2. ()GHz X 2 ・メモリ : IGB ・ OS : Red Hat Linux 7.3 IPv6 用の Web ページ http://senbatsu.v6.mbs.jp/ では、リノヾースフロキシー・エンジン Chamomile を利 用しました。 Cham 。 mile がアクセスしにくる IPv4 側に Web サーバーを 1 台用思し、 IPv6 向けのコンテンツは この Web サーバーロ褓内しています ( 図 2 ) 。 2. ISP 参加型 CDN 実験 ( 2 ) 1Mbps の広帯域映像の提供 (Windows Media 8 による CDN 配信実験 ) 3. IPv6 配信実験 Web については、リノヾース・フロキシー Chamo- mile を用いて IPv4 工竟から自重加己信。ストリー ングについては、 Windows Server 2003 を用いて Windows Media 9 て酒己信 システム全体の概要を図 1 に示します。 WWW 配信システム 今回公開した http://senbatsu.mbs.jp/ というべー ンン 178 UNIX MAGAZINE 2003.7

8. UNIX MAGAZINE 2003年7月号

広告企画■進化した次世代ストレージ 一分散する膨大なデータを統合管理ー ストレージは企業のビジネスインフラ 企業の情報システムが取り扱うテータは、ここ数年で質的・量的に大きく変化した。ネットワーク上で、予想 できない大量アクセスにも柔軟に対応し、 24 時間・ 365 日のサービスを提供するには高度な信頼性と拡張性 を備えたストレージが不可欠といえる。増え続ける情報をいかに管理すべきか・・・。最新のストレージ技術 第 を紹介する。 ーテータ量の増加とともに ストレーシの重要性が高まる インターネット、とくにプロードバンドの普及にともない、 ネットワーク上を流れるデータ量は急速に増大している。 取り扱うべきデータ量の拡大とともに、データを安全に 格納できるストレージ・システムへの要求も、より高度な ものになりつつある。ネットワーク上に分散するデータを 統合して管理コストを抑制できること、あわせて、高性能 で高信頼性を実現することが求められているのだ。デー タを統合管理するために利用されているストレージ技術 には、大きく分けて「 SAN (Strage Area Network) 」と 「 NAS (Network Attached strage) 」がある。 SAN は、ファイパ・チャネルを使ってサーバとディスク装 置をつなぐストレージ専用のネットワークで、接続には LAN と同様にハプやスイッチが用いられる。そのため、 拡張性が高く、柔軟なネットワークを構築できることが特 徴だ。企業にとっては大きな IT 投資となる、高価な大容 量テープライプラリや MO ライプラリ、ディスクアレイなどを 複数のサーバで共有できること、高速データ転送により、 ストレージに格納されたデータのバックアップ時間を大幅 に短縮できること、また、ストレージ装置とサーバを離れ た場所に設置することも可能なため、地震などの自然災 害や停電など不慮のアクシデントが発生した場合でも被 害を最小限に食い止めることができる。もちろん、デバイ スやサーバの増加に柔軟、かっ、簡単に対応でき、高 速・大容量のストレージ装置にデータを統合することで膨 大で散在するデータの管理コストを削減できるほか、デー タ処理の高速化を図れる。 一方、 NAS は、 Ethernet など企業内でも一般的に利用 されているネットワークにストレージを接続するために UNIX や Linux 、 Windows などさまざまなシステムから利 用できるストレージ装置といえる。つまり、 SAN がストレー ジ・ネットワークであるため、異機種間での利用には特別 な工夫が必要であるのに対し、 NAS は異機種間で利用 でき、サーバからデータを共有可能な、高速・大容量のフ ァイル・サーバ専用機といえるのだ。企業など利用者にし てみれば、 SAN と NAS もデータの統合化、データ処理の PR 高速化、データ確保の高信頼などの点で機能的に大きな 差異がなく、どちらを選択すべきかを迷ってしまうかもし れない。しかも、最近では NAS と同様に異機種間でも利 用できる SAN を実現してくれるストレージ装置も数多く市 場に投入されているほか、 SAN と NAS を融合して利用し ようという動きも顕著になっている。 ストレージの導入がもたらす ティサスタ・リカバリ SAN 、 NAS ともに従来のサーバ直結型ストレージとは 異なり、ネットワークを経由してサーバに接続されるネット ワーク型のストレージである。サーバからストレージが独 立しているため、サーバごとに管理を行う必要がなくなる ほか、サーバとは別個にストレージだけを拡張できるため 投資コストを最適化できる。しかも、サーバ直結型ではな くネットワークを経由するために、高速なネットワークやイ ンターネット上にストレージを設置しておいても利用可能 だ。今後、数年で企業、個人が取り扱うべきデータは 急増し続けることは容易に予測できる。そのため、多くの サーバにデータを分散して抱えている企業などにとって は、増え続けるデータを統合管理できる SAN や NAS は有 効な技術といえる。データ、すなわち情報とは、以前は企 業や個人、データを利用する人の業務を支援するものだ ったといえるが、最近では、情報を効率的に扱えるように する情報システムそのものが企業の根幹を支えている。 万が一にでも情報システムが支障をきたせば、企業経営 の視点から致命的な損害をもたらす可能も否定できない。 情報システムがビジネスのインフラそのものとなった今、 安全で信頼性が高く、大容量のデータを効率的に管理・ 統合できるストレージ・システムの導入は大きな意味を持 つ。さまざまなソリューションが登場し、電子商取引やデ ータウェアハウスなど、扱うデータ量が膨大になるとバック アップも重要となる。バックアップ機能も充実し、アプリケ ーションの稼動中にバックアップするオンライン・バックアッ プや、ネットワーク経由で実行するネットワーク・バックアッ プなどの機能を備えたストレージの導入は、デイザスタ・ リカバリという視点でも重要な意味を持つ。

9. UNIX MAGAZINE 2003年7月号

特集 LDAP でネームサービス 1 If you are not using administrative domains, press Enter to select the default . Otherwise, enter some descriptive, unique name for the administration domain , such as the name Of the organlzation responsible for managlng the domain. Administration Domain C10ca1net] : nspl . com 管理ドメインは、 iPlanet ソフトウェアに関する情報を保 存する設定ディレクトリ・サーバーの一碚にである。複数の ソフトウェア・リリースを同時にイ目したり、複数のドメ インを管理するのなら、管理ドメインを利用してそれらを 区別するとよい。 管理ドメインを利用する必要がなけ川ま、 Enter キーを入 力してデフォルト値を j 尺する。それ以外の場合は、ドメ インを管理する細織名のように分かりやすくュニークな管 理ドメイン名を入力する。 管理ドメイン [localnet] : 【 nspl.com 】 れを使えはよい。 必要はない。テフォルトではホスト名のドメイン部カ甘勸譿れるので、そ トリ・ツリーを複数に分けなくてもよいのなら、管理ドメインを定義する 注意 : 表示される説明のようにサーバーが 1 台だけだったり、ディレク The Administration Server is separate from any Of your application servers since it listens tO a different port and access tO it is restricted . Pick a port number between 1024 and 65535 tO run your Administration Server on. You should NOT use a port number which you plan t0 run an application server 0 Ⅱ , rather, select a number which you wiII remember and which will not be used for anything else . The default in brackets was randomly selected from the available ports on your system. TO accept the default , press return. Administration port [ 19884 ] . 管理サーバーはアプリケーション・サーバーとは別物で、 待ち受けるポート番号が異なり、アクセスも制限されて いる。 管理サーノヾーが待ち受けるポート番号は、 1024 ~ 65535 のなかから選ただし、アプリケーション・サー が使うポート番号ではなく、憶えやすく、他で使用されて いない数値にする。 角瓜内に示したデフォルト値は、使用可能なポートのな かからランダムに選択したものである。デフォルト値を選 択するには Enter キーを入力する。 管理サーバーのポート番号 [ 19884 ] : 【 3000 】 The Administration Server program runs as a certain user on your system. This user should be different than the one which your application servers run as . 0 Ⅱ 1y the user you select wi11 be abIe tO write tO your configuration files . If you run the Administration Server as "root't , you wi11 be able tO use the Server Administration screen tO start and stop your application servers . Run Administration Server as [root] : 管理サーバーは、システムの指定されたユーサーの権限で 動作する。これは、アプリケーション・サーバーがその権 限で動作しているユーザーとは異なるものでなければなら 114 ない。ここてオ旨定したユーサーのみが、成疋ファイルを上 書きすることができる。管理サーバーを root で実行する と、管理サーバーの画面でアプリケーション・サーバーを UNIX MAGAZINE 2003.7

10. UNIX MAGAZINE 2003年7月号

連載 / IJN Ⅸの道具箱ーの 了します。 ()P アドレス ) を書いておきます。 $HOME はホーム・ 機で下記のいすれかのファイルにクライアントのホスト名 川い 証でログインできるようにするには、サーバー側の計算 る計算機に対してはこの認証方法は使えません。 . rhosts れている場合しか利用できません。つまり、初めて接続す こないます。ただし、サーバー側のホスト公開鍵が登録さ す前述のホスト認証をおこなったあと、 . rhosts 認証をお これに対し、 RSA ホスト認証付き . rhosts 認証では、ま 定により許可されていません。 キュリティ上の問題が大きいので、通常はサーバー側の設 アドレスを偽装することで簡単にすり抜けられるなど、セ ホスト認証をおこないません。そのため、計算機名や IP 用いた認証とまったく同しガ去で認証されます。つまり、 . rhosts による認証は、 rlogin や rsh での . rhosts を (DSA) 公開鍵による認証を利用すべきです。 が使えるため、認証の安全陸を考えればなるべく RSA ワードよりもはるかに長い文字列 ( 通常は 10 ~ 30 文字 ) (DSA) 公け懾正で用いるパスフレーズは、 UNIX パス 攻撃などによって破られてしまうかもしれません。 RSA 般に UNIX パスワードは 8 文字以下なので、総当たり にパスワードを流すことに変わりはありません。また、 しかし、暗号化されているとはいえ、ネットワーク上 は暗号化されています。 ます。もちろん、ホスト認証か終っているのでパスワード そこでパスワード・データベースによる認証がおこなわれ rlogin や telnet と同様にパスワードをサーバーに送り、 証がおこなわれます。 UNIX パスワードによる言正では、 録していない場合、通常は UNIX パスワードによる認 ューサーがサーバー側の言 t 算機にユーサー公開鍵を登 徴です。 ならない青幸ゞまったくネットワーク上を流れないのカ畤 この手順では、パスワードや鍵など、他人に知られては ディレクトリを表します。 ・ $HOME/. rhosts ・ $HOME/. shosts ・ /etc/hosts. equiv ・ /etc/shosts. equiv 92 これは、あとで説明する OpenSSH を利用するサー ノ、 ーの場合です。はかの SSH サーバーでは場所が異なるか もしれません。また、 OpenSSH の場合でもサーバーの設 定により変更できます。 SSH2 では s / key によるワンタイム・パスワードも利 用できますが、 OpenSSH のデフォルトの設定では 0 仕に こでは省略します。 なっているため、 SS Ⅱのインストールと準備 それでは、 SSH のインストールとログインするための 準備について説明します。 どの SSH を使うか 前述のように、 SSH には複数のバージョンがあり、実 装もフリーのものや商用のものなどさまざまです。そうな ると「じゃあ、どの SSH を使うのがええのんや ? 」と悩む 方もいるでしよう。その答の 1 つが「 UNIX なら ()per ト SSH 、 Windows なら PuTTY 」だと思います。 OpenSSH は SSHI と SSH2 の両方に対応しており、 完全にフリーな実装なので誰でも使えます。転送するデー タを gzip ) 疇宿することができたり、次回に紹介する予定 の X のフォワーディング機能など、さまざまな利点もあ ります。さらに、 FreeBSD や NetBSD 、 Debian など 多くの OS て驃準でインストールされます。 Windows で SSH というと、 Tera Term に拡張 SSH モジュールを使った TTSSH が有名ですが、 TTSSH は SSH2 に対応していません。それに対し、 PuTTY は SSHI と SSH2 をサポートしているため、より安全な通 信カゞ可能です。 そこで、以降では OpenSSH と PuTTY を使って説 明していきます。また、ログインする言 1 算機も OpenSSH のサーバーか動いているものとします。 OpenSSH OpenSSH は、多くの UNIX 系 OS で ports や pkg- src などのパッケージ・システムを利用して簡単にインス トールできます。たとえ tiFreeBSD なら、 ports コレク ションの security/openssh-portable になります。必要 なライプラリなども自重加勺にインストールされます。 % cd /usr/ports/security/openssh¯portable % su UNIX MAGAZINE 2003.7