AppleInsider: Mac OS X Leopard に向かって: ペアレンタルコントロールおよびディレクトリサービス [Page 2]
Mac OS X Leopard に向かって: ペアレンタルコントロールおよびディレクトリサービス [Page 2]
Published: Tuesday, October 23, 2007 10:05 AM EST
NetInfo の問題
しかし、NetInfo は問題を引き起こす可能性を抱えていた。 というのも、DNS ルックアップの要求が NetInfo 経由でルーティングされていため、外部の DNS サーバが応答できないと、他のルックアップ情報が実行できないがために、システムはそこで反応を待ったままスタックしてしまう可能性があったのだ。 さらに、NetInfo はそのユーザアカウント情報をローカルなデータベースに保存していたため、そのデータベースに問題が発生した場合、ユーザはシステムをシャットダウンして、バックアップからそのデータベースを復旧するか、壊れたデータベースを削除してまた新しく作り直すか、手で全てのローカルアカウントを再作成するかしなければならないのだった。 Unix システムであれば、壊れた Users テキスト設定ファイルを手動で修正したり再構成したり、あるいは正常なバージョンにその場で置き換えることも簡単だった。
ユーザ文書は NetInfo による問題の影響を受けなかったし、ユーザのアプリケーション設定や設定項目も影響からは無縁だった。なぜなら、これらすべてはユーザのホームディレクトリに分けて保存されていたからだ。 NetInfo データベースを再構成した後、ユーザが再度ログインしさえすれば、すべての設定やファイルはこれまで通り表示された。
NeXT は、他の Unix ライクなシステムにも NetInfo を販売しようと計画を立てたものの、ほとんど関心を引くことはできなかった。 Sun はまた、元の NIS にあったセキュリティ問題に対処するため新たに見直されたシステム である NIS+ にもほとんど興味を示さなかった。 替わりに業界は、単一のベンダーに影響されない、オープンで相互運用可能な標準を模索し始めた。
標準化されたディレクトリ管理: X.500
ITU、後の ISO が率いる国際標準化団体は、80 年代になるとネットワーク運用における相互運用性の策定に着手した。 それまで PC およびワークステーションのユーザ間で利用されていたネットワークプロトコルは、Apple の AppleTalk、Novell の NetWare、Digital の DECnet、IBM の SNA、そして Microsoft の LANmanager などすべて特定のベンダーによる独自のものだった。
ITU は、電子メールのための X.400 およびディレクトリサービスのための X.500 など、Open Systems Interconnection と呼ばれる一連のネットワーク標準を設定した。 主要なベンダーはその新しい標準、とくにディレクトリサービスへのサポートを表明した。Apple は自社の PowerTalk 電子メールアーキテクチャに X.500 ゲートウェイへのサポートを組み込み、Novell は 1993 年に X.500 をベースにした同社の Novell Directory Server リリースし、さらには Microsoft が同社の 1991 年の Cairo ヴィジョンで X.500 へのサポートを約束した。この Cairo ヴィジョンは、Microsoft's Yellow Road to Cairo にあるように、やがて 1996 年に Exchange Server の一部として世に送り出された。
OSI の開発は、Internet Society によって提案されたよりシンプルでより効果的な標準の登場によって急速にほころび始めた。 OSI を構成する企業のニーズを代表するのではなく、インターネットコミュニティによって開発されたネットワークのためのオープンな代替標準は、実際のユーザのニーズを反映していた。 1996 年までには Apple's Open Source Assault にあるように、OSI の失敗によって大企業の戦略は崩壊し、インターネット標準をサポートするために急いで設備を改善せざるを得なかった。
OSI の官僚主義が原因で、仕様は重く非効率的で、さらに複雑になってしまっていたのだ。 それとは対照的に、インターネットプロトコルを提出するためのプロセスは、よりオープンで競争力に満ちており、優れた提案は Internet Engineering Task Force によって管理されていたピアレビューを受けた Request For Comment プロセスを通して進展できるようになっていた。その次の段階として、インターネット標準として採用され、実装され、実証された RFC プロポーザルとなっていった。 一方の OSI がやったことといえば、単に理論的な標準の草案を書き上げたことくらいだった。
1995 年ミシガン大学が、インターネット経由で X.500 ディレクトリデータへとアクセスできるようにする作業を開始した。 X.500 Directory Access Protocol は必要以上に複雑であるとの結論に達した同大学は、Lightweight Directory Access Protocol と呼ばれる代替プロトコルを開発した。 LDAP は、特別に調節されたデータベースを利用して、NetInfo と同じように、インターネット越しに探索したディレクトリ情報を返したが、同プロトコルは、相互運用可能なオープン標準として実装されていた。 LDAP はまた、Sun の NIS にはなかった認証および暗号化サービスも提供した。これにより、Unix ディレクトリサービスは急速に LDAP へと移行するきっかけとなった。
Novell および Microsoft もまた息をせききって、彼らの PC 用ディレクトリサービス製品で LDAP サポートを提供した。 1996 年、Novell は NDS 用の LDAP プラグインを発表し、一方の Microsoft は同社の X.500 製品を登場させた。 Microsoft はこの年、LDAP をサポートするという同社の計画を発表し、4 年後に Windows 2000 の一部として Active Directory 1.0 を初めて発表した。 Active Directory は、Windows がネットワーク接続時に名前サービスのために利用していた独自の NetBIOS や WINS システムをはじめ、Exchange Server での X.500 ディレクトリサービスの両方に置き換わった。 Active Directory は、LDAP を「包容し拡張した」バージョンだとされるが、他のベンダーも同技術をサポートした開発を行えるだけの類似点を備えていた。
1996 年に NeXT を買収した Apple は、NetInfo システムを採用して、Open Directory と呼ばれる新しい LDAP ベースのディレクトリサービスアーキテクチャの開発を開始し、2002 年の Mac OS X Jaguar 10.2 のリリースとともに世に送り出した。 Leopard では、Open Directory はまたローカルシステム上の最後の残余をも置き換えることになった。
Apple の Open Directory はまた、Microsoft の Active Directory や、今や企業内では幅広く採用されている標準の LDAP システムに接続でき、「BSD Flat Files」と呼ばれるローカルの Host ファイルといった、システム上の標準の Unix ファイルを参照することもできるようになっている。 一旦ディレクトリサーバに接続すると (上図)、システムは与えられたネットワークアカウントでログインできる。
Open Directory は、認証に MIT の Kerberos シングルサインオンをサポートしている。 Open Directory ユーザとしてログインしたユーザは、自分の証明書を Kerberos によって他のサービス上へと安全に受け渡せるようになる。 つまり、サインインしたユーザは、認証が必要なファイル共有サービスやネットワークリソースに繰り返しユーザ名やパスワードを提供しなくてすむのだ。
Open Directory はまた、Windows PC の Domain Controller のようにも機能でき、PC ユーザが Mac にログインする際のと同じアカウントを利用して、同じサーバ上のローミングプロファイルやホームディレクリにログインできるようにしている。 これは、Server Admin (下図) で設定されており、Samba オープンソースプロジェクトによって提供されている機能をベースにしている。
Managed Preferences の起源
NetInfo はディレクトリサービスを参照していたが、ユーザの設定項目までは管理していなかった。 こうした設定はすべて、NetInfo システムからは切り離された通常の設定ファイルに保存されていた。 他の Unix システム同様、NeXT も設定値をテキストファイルに保存していた。
そこで、NeXT はプロパティリストと呼ばれる構造化されたファイル形式を導入した。 というのも、ちょうど Unix の設定ファイルと同じように、ファイルは人間が読める形式で、手で編集できるものだったからだ。 ところが、NeXTSTEP のグラフィカルな環境では通常、Preferences アプリケーション (下図) からといったように、自分で「plist」ファイルを更新していた。 ファイルは特定の構造をもって整理されていたので、グラフィカルインターフェースのどこにも表示されていないような項目でさえ、システムの Defaults コマンドでも設定値を管理・更新できた。
Apple の Macintosh はシステムの Preferences ファイルをバイナリーファイルで保存していた。というのも、そうしたファイルは手で編集したり、コマンドライン環境で編集することを想定していなかったからだ。 設定ファイルが壊れてしまった場合、解決法はそのファイルを削除することで、アプリケーションはそうした対処法に対応できるよう設計されていた。 立ち上げられたアプリケーションが自らの設定ファイルを見つけられない場合は、新しい空白のファイルを作成することが求められていた。 設定を削除するという手順は、便利な問題解決のステップだった。というのも、壊れたファイルは通常あらゆる問題を引き起こす可能性があったからだ。 そうしたファイルを一旦削除してしまえば、アプリケーションは単に標準設定へと戻り、ユーザは作業に復帰できたのだった。
ページ 3 / 3: Microsoft の Windows Registry; Mac OS X での Preferences; Managed Preferences; Leopard の新機能: ペアレンタルコントロール; そして Leopard での新機能: Employee Policy および Organizational Directory。
前のページに戻る