実際にクライアントからログインするためには、クライアントの設定の一部を変更する必要がある。システム環境設定の「ログイン」にある「ログインウインドウ」のタブで、「自動的にログイン」は基本的にはチェックを入れないことになるだろう。そして、ログイン時の表示で「名前とパスワードの入力欄」を選択するか、あるいは「このコンピュータに…」を選択した場合には、「ネットワークユーザとして“その他のユーザ…”をリストに表示する」のチェックを入れておく。いずれにしても、アカウント名とパスワードを入力する枠がログイン時に表示されるようにしておく。
◇「ログイン」の設定を確認しておく
こうしてログインすると、ホームディレクトリは、ネットワークの先のサーバにある自分のディレクトリとなる。以下のように、homeプロパティで指定した通り、Networkからたどっていったところがホームになる。
◇ログインしたクライアントのホームディレクトリ
Documentsをはじめとして、自分で使っている各種のフォルダが、すべてサーバにあるわけだ。結果的に、ネットワークのどのMacintoshからログインしても、ホームディレクトリは同じ環境となるというわけだ。
――――ネットワーク構築の実際
こうしたNetInfoの需要はあると言えばあるわけだが、さすがにどちらを見てもMacintoshがあまり売れていない世界だ。たとえば、学校での利用が考えられるが、Macintoshを講義で使うような場合には、学生が座る席は一定ではないし、台数以上の利用者がいるのが一般的だから極めて有効な手法だろう。Windows NT/XPでは、移動プロファイルという方法で、ログイン時に初期設定などのプロファイルのダウンロードを行う方法で、異なるパソコンでログインしても自分の環境を常に呼び出せるということは可能であり、学校教室での利用は一般的になっている。これと同等なことはNetInfoできるが、初期設定なども含めてネットワークアクセスがある。やはり多人数が同時に使う世界だけに、ネットワークのトラフィックについては設計時に神経を払うべきところだろう。
また、オフィスでの利用でもこうした使い方はあり得るものの、むしろ、1人に1台のパソコンが割り当てられるとなると、かえて、個人個人でそのマシンを使うようにする方がある意味では管理は楽な場合もありうる。また、デザイン系のユーザだと扱うデータのサイズが大きいため、ファイルをネットワーク越しに開くようなことが体感的にはなじめないだろう。ハードディスクが高価な時代はともかく、今では数十ギガが当たり前なので、コスト的なメリットもあまりないかもしれない。ただ、いずれにしても、中央で管理するということに必要性がある場合には有効な方法だろう。
仮に、200人の学生のアカウントをMac OS X Serverで管理するということになったら、1人あたり500MBとしても100GBのディスクが必要だ。そうなると、少なくとも、起動ディスクとは別のディスクにホームディレクトリを作成したいだろう。それに、まともに使うとなると500MB/人では済まないだろう。複数のサーバに分散させないといけないことにもなる。こうした場合の設定については、以下のKnowledge Baseに文書が掲載されているので、それを参照していただくといいだろう。1台の上位ディレクトリのサーバに、3台の下位のディレクトリを構築して、その3台に各学生のホームディレクトリを設定するという想定で、詳しく設定する方法が記載されている。
Mac OS X Server: Setting Up Multiple Servers to Host User Home Directories
http://www.info.apple.com/kbnum/n106571
ただ、問題としては、1ユーザあたりの使用量を制限すると言った機能が、標準では用意されていないことだ。実際にいろいろな使われ方がまだされていないMac OS X Serverだけに、具体的なニーズが出てきていないのかもしれない。
ログインの認証をMac OS X Serverにさせて、ホームディレクトリの利用はローカルにするというふうにしてはどうかという考え方もできる。そうすれば、/Network以下に、サーバが自動的にマウントできる。もちろん、その通りなのではあるが、だったら、Mac OS X Server側で認証はさせないでローカルで認証をさせ、普通にFinderからファイルサーバに接続する方が素直な使い方だろう。マウントしたサーバボリュームのエイリアスを作るなどしておき、それをシステム環境設定の「ログイン」の起動項目に入れておけば、起動時にそのサーバを自動的にマウントする。キーチェーン等の設定をしておけばすべて自動で行える。どちらが容易かは一概には言えないかもしれないが、わざわざNetInfoの設定をいろいろいじるほどのメリットは薄いと感じる。
クライアントを上位のディレクトリに接続するようにしたとき、クライアントと上位ノードに同じアカウントを設定した場合どうなるかであるが、基本的にはクライアント側しか参照しない。たとえば、同じアカウントで異なるパスワードを設定しても、上位のノード側のアカウント情報ではログインはできない。認証するディレクトリの順序を決めることがDirectory Setupでは可能だが、ローカルなディレクトリは最優先で使われる設定に変更はできない。このことを考えれば、たとえば、何台かのMacintoshでMac OS Xを使いはじめて、それからしばらくしてMac OS X ServerのNetInfoをベースにして使うといったことへの移行はけっこう大変だということが想定される。サーバに設定するアカウントを意図的に変えるということをするなどの工夫が必要になる。
アプリケーションの「NetInfo対応」ということも気になるところだ。ソースコードに「/Users/ユーザ名」的なパスの直書きがあると、上位のノードにログインしたときの動作は保証されないだろう。もちろん、システムからホームディレクトリを得て、その結果をもとにパスを構築するような形態になっていないと、問題が生じる。また、アプリケーションについても、同様にNetInfoの上位ノードにアクセスして共通に使うということもあり得るわけだが、その場合も、絶対パスでの動作が組み込まれていないようにする必要がある。今ははNetInfoベースで使うユーザはほとんど見られないにしても、将来は分からない。開発者としては、こうした環境もあり得ることは頭に入れておくべきだろう。
∽∽∽∽∽∽∽この項、以上∽∽∽∽∽∽∽[新居雅行]∽∽∽∽∽∽∽