併設見学会: 大阪大学情報処理教育センター

Last modified: Wed Sep 3 20:03:57 1997

大阪大学情報処理教育センターを見学させていただいた。以下、気がついたことをトピック的に記述する。

NEXTSTEP と PC

情報処理教育用の機器として導入されているのは NeXT および PC 互換機 (SONY QuarterL: Pentium 75MHz + 32MB memory) で、 PC 互換機では NEXTSTEP for Intel が動作している。すこし触らせていただいたが、「きびきびと」とまではいかず、すこし重い感じであった。最近の標準的な PC (PentiumPro 200MHz など) であればストレスなく使用できるであろう。

NeXT/NEXTSTEP を導入したのは

Mac, Windows では大規模管理ができない
ふつうの UNIX はふつうの人には使えない

からだとうかがった。両者を同時に満たすのが NEXTSTEP というわけだ。実際に操作してみると、たしかに「MacOS ライク」な操作感である。 Drag & Drop に関しても、 MacOS 7.5 以降でおなじみの「なんでも Drag & Drop」とほぼ同様のイメージで操作できる。ただし、文字列の Drag & Drop はできないようだった (ほんとはできるのかもしれない)。


学生用 PC		教卓の PC とビデオプロジェクター

PC のディスプレイには 1-542 教室と同様のものが採用されていた。また、PC 用のディスプレイとは別に、TV 用のディスプレイが 2 人に 1 台の割合で設置されていた。講議は通常この TV 画面を通して行うとのこと。テキストを用意しビデオプロジェクター (教卓の写真右の OHP のような機械) で TV 画面に写したり、PC のディスプレイをそのまま画面に写したりできる。 1-542 教室のような「数台の大型 TV」形式より遥かに見やすい。しかし、1-542/609 にはもはやディスプレイを置く場所がないので、この形式を採用したくてもできない。


PC 正面		PC 裏面

ハードウェアの障害/盗難対策にはかなり気をつかわれていた。 PC 感覚で電源 OFF/リセットをされるのは困るし、採用しているハードウェアはどこにでもあるふつうの PC なので、盗まれる可能性はワークステーションよりはるかに高いと考えなければならないからだ。具体的には、次のような対策がなされていた。

本体正面には、電源、リセットなどのスイッチが一切ない (正面にリセットスイッチらしきものが見えるが、これは機能しないようになっている)。
フロッピーから boot できない。boot は内蔵 IDE からのみ。bios にはパスワードをかけてある。
電源などのケーブルに南京錠 (写真赤丸部分) がついているので、簡単には抜けない。

今後、理工学部でも PC の採用が考えられるが、その際には障害/盗難対策に十分留意する必要がある。

また、大阪市立大学で採用されているというセキュリティボード (オブジェクト(株) パワーマネージメントシステム) が紹介された。これは上記のような障害/盗難対策をさらに徹底して行うための装置だが、大阪大学では資金的な面から導入を見送っているようだ。

フリーソフトやユーザサポート、ドキュメントなどの環境整備にはボランティアを募って行っているとのことであった。 RINS では金を出してアルバイトを雇っているが、ヤル気のないアルバイトよりもヤル気のあるボランティアを募集し、そのボランティアにある程度自由にできるリソース (機器など) を与えたほうが、よりよいサービスを実現できそうな気がする。今の RINS アルバイトは投入資金に見合った機能を果していないし、機能させたくても使いにくいと私は感じている。

ネットワーク

大阪大学のネットワークは、龍谷大学と同様 ATM を基幹としたものである。使われていた機器は:

基幹 (ATM): NEC ATOMIS7
ATM ←→ Ether: CISCO Catalist5000


NEC ATOMIS7		CISCO Catalist5000

シンポジウムにて解説された高知工科大学のネットワーク機器も ATOMIS7 + Catalist5000 であり、龍谷大学の ATOMIS7 + D3000 とは状況が少々異なる。

ファイルサーバには SONY 製のディスクアレイ (RAID5) が使われていた。 RAID5 を使う場合、RAID コントローラが故障すると全てが失われるというリスクがあるが、大阪大学では、コントローラが故障する事態は発生していないとのことであった。

管理

● ユーザ ID

ユーザ ID は次のように設定しているとのこと:

学部 (2文字), 年 (1文字), 学籍番号 (3文字), イニシャル (2文字) 例: sb7012tt

職員は「年 (1文字)」が -、ゲストユーザは v となっている。

Internet 電子メールを本格的に利用するとなると、本学部の「学籍番号そのまま」の ID では、電子メールの誤配が多発するおそれがある。 ID 設定ルールの変更を考慮すべきときかもしれない。

● パッチシステム

各ホストに対する設定変更作業はたいへん繁雑なものである。また、トラブルなどで一時停止しているホストに対してはトラブル解消後にあらためて設定変更を行わなければならないなど、どのホストにどの作業を行ったか (行っていないか) を覚えておく必要がある。これが繁雑さに拍車をかける。

これに対し、大阪大学では「パッチシステム」を導入した。これは次のように動作する:

各マシンはそれぞれ「パッチレベル」という値を保持する。パッチレベルは「どれだけパッチを適用したか」を示す値である。
サーバ上にあるパッチファイルを参照し、自分のパッチレベルよりも大きければ、そのパッチファイルをマシンが自動的に パッチを適用し、自分のパッチレベルを上げる。自分のパッチレベルがサーバ上のパッチファイルに追いつくまでこれを繰りかえす。

この場合、各マシンが自動でバージョンアップしてくれるので管理負荷が下る一方、パッチファイルの管理という新たな負荷が発生する。差し引きするとどうなるかは組織によって異なるだろうが、魅力的な管理手法である。

● NIS

単に NIS 共有を行うと、NIS サーバがハングすると各マシンまでハングしてしまう。そこで、大阪大学では次のようにしているそうだ:

起動時にパッチファイルの NFS マウントを試み、失敗した場合は NIS を使用せずに起動する (→ メンテナンスできる)。
パッチファイルが読めるようになると、自動で再起動する (→ NIS が使えるようになる)。再起動するタイミングは、即時、ユーザログアウト後、などからこれも自動で選択する。

私について