2003年4月号掲載よしだともこのルート訪問記第78回

2003年4月号掲載よしだともこのルート訪問記

第78回利用者3万人、UNIXとWindowsの共存はVirtual Machineで実現
～京都大学学術情報メディアセンター（2）～

前回に引き続き、京都大学学術情報メディアセンター注1の丸山伸（まるやましん）さんを訪ね、このセンターが提供している新システムにおけるUNIXとWindowsとの共存方法のほか、メールの読み書きにWebメールを導入された理由と効果、そして、大規模システムであることの苦労や工夫を中心にお聞きしました。

丸山伸（まるやましん）さん
1998年4月から京都大学の教育用計算機システムにかかわり、現在、京都大学学術情報メディアセンター助手。

※所属部署・肩書は取材当時（2003年2月）のものです。

■利用者用PC端末のUNIXとWindowsの共存について

よしだ（以下、Y）：前回は、利用者3万人という教育用計算機システムの歴史的な流れと、新システムの3つの柱を中心にお伺いしました。今回は、まずUNIXとWindowsとの共存についてお伺いしたいと思います。
　1998年2月から2002年1月31日まで利用された旧システム注2では、合計約400台のUNIX WSが置かれた部屋と、合計約800台のWindows NTの置かれた部屋が別になっていましたが、新システムでは共存になりましたね。

丸山さん（以下、M）：はい。旧システムでは全体的な傾向として、Windows端末の稼働率は高く、UNIX端末の利用率は低かったのです。ときどき、UNIXの部屋の利用率が高いなぁと感じることもありましたが、これは、UNIXを使用する授業の課題に、提出期限ギリギリになって取り組む学生が集中したためです。
　新システムを設計するにあたり、予算も端末台数も限られているわけですから、この状況を重視して「いっそWindowsのみにすれば」という声もありましたが、「コンピュータの原理を教育するにはUNIX環境が必要だ」という教師側の声にもこたえる必要があるため、新システムにおいても両方の環境を用意する必要があると考え、Virtual Machine（以下、VM）によって実装しました。

Y：VMを使った理由を教えてください。

M：デュアルブート方式でUNIX系とWindows系とをユーザーに提供することも考えましたが、オンラインでソフトウェアをメンテナンスすることを考えると、どちらのOSが起動されているかを意識しながら作業するのは管理コストが高いと判断して、今回はVMを活用することにしました。
　結果として利用者用端末注3には、DVDによる映像再生やUSBによる各種I/Oサポートを考えて、WindowsをホストOSとして採用し、ゲストOSには安定性と日本語対応に定評のあるVine Linuxを採用しました。また、VMは入札の結果、VMware 3.1に決まりました。
　この方式を採用したことで得られたもう1つの利点は、クライアントからのファイル共有プロトコルがNFSにまとめられたことです。VMはWindowsの利用開始とともに自動的に起動され、VMの配下でSambaを実行することでWindowsからのSMBによるファイル共有要求をNFSプロトコルに変換するようにしました。
　一般的に、UNIXのファイルサーバーにWindowsを接続するには、Windows側に譲歩してもらう方法として、「Windowsにマイクロソフト提供のService for UNIXのようなソフトウェアを導入してSMBをNFSに変換する方法」と、逆にUNIX側に譲歩してもらう方法として「UNIXにSambaを入れてSMBを使えるようにする方法」とがあります。この2つのどちらを採用しようかと検討しましたが、結論としてどちらも却下となりました。
　まず前者の方法を採用しなかった理由は、この種のソフトウェアではNFSバージョン2しか使えなかったり、ユーザー数が7万人という環境に対応できなかったりしたためです。また、Windows側のユーザー名とUNIX側のUIDとをどう対応付けるかを考えたとき、NISを利用するのがほとんどなんですよね。NISに関しては、私が過去に大トラブルを経験注4していることと、NISにはセキュリティ的に甘い部分がある注5ことから、今回のシステムではNISは使いたくなかったのです。
　また後者に関しては、検討している当時、千数百台のクライアントからの要求を1システムのSambaで処理可能という実績がどこにもなかったので見送りました。ファイルサーバーという安定運用したい場面で、あえて実験をする必要はないと判断したからです。
　結局、今回は「クライアント端末で動作しているVMを活用し、そこで動作しているSambaを利用してSMBからNFSへのプロトコル変換を行う」という方法を採用しました。こうすることで、両者のいいところをとりあえるんです。つまり、大規模にクライアントがアクセスしてくるファイルサーバー側では大規模運用で実績のあるNFSを利用できますし、クライアント側はどこかのマシンがSMBのサービスを提供してくれているように感じるというわけです。
　ただ、今回のようにVMを活用してUNIXとWindowsを共存させた環境に対しては、一部の教官から「UNIXがWindows上のアプリケーションのように見えてしまう」との指摘がありました。教育現場において学生にUNIXを使わせたい理由としては、UNIXのコマンドやプログラミング言語を教えるためだけではなく、少しでもOSの本質に近い環境を使わせることで、その仕組みを学ばせたいこともあります。しかし、UNIX環境がWindowsの中で動いていたのでは、UNIXがおもちゃのように見えてしまうというわけです。

Y：なるほど。でも、Windowsにログインしたあとで「利用者の操作でVMwareを起動」してUNIX環境を用意するのではなく、ログイン認証後の一連の流れで自動的にVMwareが起動されるようになっているのが、スムーズでいいですね。

M：はい。Windowsを起動してからそのアプリケーションの1つとしてVMwareを起動させるような手順では、いかにもUNIXはWindowsの上のアプリケーションに見えてしまうので、これを少しでも緩和したいと考えました。そこで、ログインの部分に大きく手を入れて、起動時に、Windows 2000を使うのか、UNIXを使うのかをユーザーが選択するようにしました。
　ログイン部分に手を入れた別の効用として、Windowsサーバーを使わなくても済というむこともありました。
　今回のシステムにおいては、ユーザー認証とユーザーの環境設定の部分は、Windowsに任せたくないという強い希望がありました。ほかの大学でも、プロファイルの容量が大きくなってコピーに失敗したとか、低速ネットワークで接続されてデスクトップに置いていたファイルが消えたというクレームが聞かれると思いますが、京都大学においても、旧システムのWindows環境ではユーザー認証とユーザー環境の設定を、Windowsのサーバーに任せていたため、この症状が頻繁に起きていました。
　この症状がでるそもそもの原因は、Windowsの想定しているログイン方式が、教育環境向けの環境、とくにこの規模での運用には適応しないからです。
　新システムは、安定した運用を第一に考えて設計したので、「Windowsサーバーに頼るのをやめたい」とまず考えました。その結果として、現在各部屋に置かれているWindowsのサーバーは、ウイルススキャンだけを行っており、システムに必須のサーバーではありません。
　また、前回、「利用者側がリムーバブルディスクを持ち歩くようになるだろう」という話をしましたね。そうなれば、ホームディレクトリが不要という状態がでてくると思います。そこで、2002年9月末の再インストール作業で、ログイン画面の「Windows 2000を使う」、「Vine Linuxを使う」の選択に加えて「メールとWebのみ」という選択肢が追加されました。これを選ぶと、VMwareを使わないためホームディレクトリにアクセスできませんが、そのぶんログインしてからWindowsが使えるようになるまでの時間が、圧倒的に速くなります。

Y：これは、学生が休憩時間に急いでメールを読むときに重宝しますね。ただ、この起動方法のメリットが、コンピュータに詳しくない学生には理解できないかもしれませんね。

M：きちんと広報する努力はしています。センターのWebページで、この環境のメリットと制限内容を説明注6していますので、それを読めば分かると思います。

■メールの読み書きにはWebメールを導入

Y：新システムでは、WebメールであるActive!Mail注7が標準のメーラーになりましたね。

M：京大において、メールを利用する人の数はまだまだ増えると考えています。メディアセンターのメールサーバーを利用する教職員も増えてきているのは、各学部や研究室ごとにメールサーバーを持っている状態から、徐々にこちらに移ってきているからだと思います。センターを利用する教職員の数が増えるに従って、自分のメールを読む環境を設定してほしいという教職員への対応が追いつかなくなると考えました。実際、旧システムの最後の段階では、ユーザー応対の大半が「メールがうまく読めない、設定してほしい」というものでした。
　私たちとしては、セキュリティを考えると、学外からメールを読む場合はSSLを使ってほしいのですが、IMAPやPOPを利用して読むメーラーの場合、SSLの設定をすべての利用者に要求するのには無理があります。
　Webメールの何が便利かというと、「メールを読む」というボタンさえ押してもらえば、こちらが設定した「学外からはSSLを使う」という環境を使って簡単にメールを読み書きできることです。教職員は、海外も含めて出張先からの利用が多いという点も、Webメールが教育環境に適している理由です。
　もちろん、IMAP4やPOP3、SMTPを利用するメーラーの利用も認めています。この場合、SSL経由であれば、学外からも利用可能としていますので、パワーユーザーはWebメール以外の自分で使いやすいメーラー環境を作ることもできます。

Y：新システムのメールアドレスは、学生が独自に設定できるようになりましたね。

M：はい。これまでの学生証番号をベースとしたメールアドレスを廃止して、XXX@YYY.mbox.media.kyoto-u.ac.jpというフォーマットに従ったメールアドレスを、利用者の希望で設定できるようにしています。規則に従った一連のメールアドレスを使わないことで広告メールなどが一斉に送信されることを防いだり、大学院に進学したり転学部を行った場合においても、メールアドレスを変更する必要がないというメリットも生まれています。

■利用者3万人、大規模システムであることの苦労や工夫

Y：これだけ大きなシステムを管理されていると、それなりの苦労があるのでしょうね。

M：まず、ものがよく壊れますね。これだけ台数が多いと、一般の家で3年に一度見かけるトラブルが毎日のようにどこかで起こります。電源が抜けていたというつまらないものから、キーボードケーブルの断線やマウスの故障などのハードウェア交換が必要なものまでトラブルのレベルはさまざまです。まぁこれらは、耐久時間などを考えると予想の範囲内の壊れ方でしたが、予想のつかなかったのが、「HDDがつぎつぎに壊れる」というトラブルが導入当初からかなりの頻度で発生したことです。
　おかしいな、おかしいなといっていたところ、2002年の秋になって「HDDの製造段階でのロット不良だった」ことが分かり、現在すべての端末のHDDを予防交換してもらっているところです。

Y：1300台すべての端末のHDDを交換ですか。

M：最終的にはそうなります。台数が台数だけに、各部屋ずつ順番に交換という作業をメーカーがやっています。

Y：交換後に、HDDに必要な内容を読み込ませるような作業は、すべてリモートでできるんですよね。

M：はい。そういう仕掛けは結構しっかりと作ってありますが、それでもやはり台数が多いだけに大変な作業量となっているようです。

Y：京大はキャンパスが広いので、サテライト教室にちょっとサポートに行くだけでも大変ですよね。

M：たまに学内のサテライト教室すべてを見て回りますが、自転車でも丸一日かかります。端末やキーボードが壊れていないか、プリンタがきちんと動いているか、マウスがなくなっていないか（笑）程度を見て回るだけですが、それだけでも午前中に半分、午後に残りの半分というふうになってしまいます。

Y：お昼休みもセンターには戻らずに？

M：はい。午前中に総合人間学部とその図書館、経済学部、文学部、工学部、農学部を回って、北部キャンパス内の食堂で昼食をとり、午後に理学部、教育学部、図書館、医学部、薬学部、医療短大を回るのがお気に入りのルートです。
　また、サテライト教室に関しては、端末とネットワークの管理以外の管理は学部に任せています。

Y：なるほど。ゴミ箱の処理や掃除は各学部の責任になるのですね。

M：はい。だから「この部屋は汚いせいで端末が壊れやすいからきれいにしてね」とか「節電のために冷房を切りたくなる気持ちは分かるけど、つけておいてね」といったことを、学部の管理者にお願いすることになります。サテライト教室のプリンタ用紙、電気、冷房などの費用は学部持ちです。
　ところで、最近は何かのトラブルで部屋に駆けつける頻度は減っています。それは「見に行かないとどういう状況なのかが分からないような止まり方をしなくなった」、「業者さん、技官さんにお願いできるようになった」からで、これは大変な進歩だと思います。
　旧システムでは、Windows NTを使っていましたが、私が赴任した1998年当初は、Windows NTを大規模システムで使うことに対して、私たちもメーカーもノウハウがなかったんですよ。そのため、Windows NTをほぼデフォルトの状態で使っていましたが、そうするとすぐにOS自体が動かなくなったんですね。UNIXだと、管理者の読み書きできる部分とユーザーの読み書きできる部分が明確に区別されていますが、Windowsの場合はそれほどはっきりしていないために、OSが次々と動かなくなりました。その対策として、「どこどこのディレクトリには、一般の利用者は書き込めないようにする」といった設定をまめに行い、一般の利用者の操作でOSが止まらないようにしました。
　1998年4月からの1年間のノウハウを基に、1999年夏にはWindows NT環境のバージョンアップを一斉に行ったのですが、それと同時にOSにいろいろな工夫を施しました。これによって、ソフトウェア的な障害はかなり減りました。それまでは、どの教室にも数台、動かない端末がある状態でしたが、この時期以降、「いま、どこどこの教室に1台、動かない端末がある」程度に減りました。
　新システムでは、WindowsのバージョンがWindows 2000になったことと、私たちの研究もあり、ソフトウェア的な障害はほとんどなくなりました。いまは、「どのファイルがなくなったから起動しない」という障害は皆無だと思います。

Y：すごい進歩ですね。

M：これは「利用者側の権限をどこまで奪うか」という話なんですが、いまは利用者全員がguestグループ権限で利用しています。マイクロソフトが設定している「guest」権限で利用するメリットは、端末の設定をほとんど変えられないことです。レジストリの書き換え権がguestユーザーにはほとんどないんですよ。レジストリの中には、海のものとも山のものともつかないものがあり、すべてを私たちが制御することは難しいということから、思い切って「全員guestグループ」としました。
　つまり、ほかの人に影響を与えるようなソフトウェアを勝手に導入できない環境です。ですから電源を切れば、必ず元どおりに動きはじめます。そのために利用者本人が困ることはあるかもしれませんが、全体が困るような障害は起こりません。

Y：利用者も大学の環境では制限があることを理解して、個人のパソコンで好きなことをすればいいわけですね。

M：そうなってほしいですし、将来的にはそうなるでしょうけど、いまはまだ、利用者のわがままを耳にしますね。こういうことができないのは不便だとか、家でできることがここではできないとか……。しかし将来においては、より共通した環境を安定して提供することに専念できるようになると考えています。

Y：なんとなく昔に戻るようなイメージですか。

M：そうです。京大では、1998年に旧システムができたときに、学内の広い範囲に教育用端末を置くようになり、新システムでもほぼ同じ台数を置いています。たぶんこの次のリプレイスでは、外（各学部のサテライト教室）に置く範囲を縮めることになるのではないかと私は考えています。端末数を増やし、あちらこちらに分散して置くことはコスト増加につながりますが、それに見合うだけのメリットが得られていないと思いますし、分散して置くことで、学部独自の要求、つまりこのソフトウェアをインストールしてほしいという要求が強くなってしまいます。それらにいくら対応したくても、いまのセンターの陣容では対応しきれないという点もあるからです。

Y：リモートでできるメンテナンス作業の種類などを紹介していただけるとありがたいですが。

M：まずは、端末起動時にスクリプトを自動的に実行するようにしている点があげられます。管理用のWebサーバーを用意しており、各端末に電源が投入された時点で、ネットワークが動いているかを確認し、その後Webサーバー上にあるスクリプトを自動的に実行します。これは、1999年の夏から実施しています。そのように作り込んでおくことで、場合に応じた、きめ細かなバージョンアップが可能となります。たとえば、「こんなアプリケーションを追加しよう」という場合、それほど大きなファイルでなければ、そのスクリプトにインストール手順を書いておけば、端末の起動時に自動的にインストールされます。
　現在、Webサーバー上にあるスクリプトは、ソフトウェアを追加インストールしていたり、セキュリティホールにパッチを当てたりしているだけでなく、新たなサービスを開始したりもしています。
　いまの運用方針ではWebサーバーを使った実習をするのは難しいのですが、VM内のLinuxでローカルアクセスしか認めない形でApacheを動かすようにもしました。
　このほかにも、Linuxをルート権限以外で再起動できなくする、リモートから端末の電源を切れるようにする、誰がいつログオフしたかのログをとるといった細かな変更をつぎつぎと行っています。もちろん、再インストール後には、これらの処理も自動的に行われるように工夫されています。

Y：長いこと電源が入っていなかった端末に電源が入ると、このスクリプトを読み込んで、これらがすべて実行されるのですね。

M：そうですが、長いこと電源が入ってない端末があるとすればそれは異常な話なので、それは別途チェックして「この端末、大丈夫かな。ひょっとして、持って帰られた？」などと冗談をいいながら調べています。

■「内部の利用者を信用するモデル」の破綻を痛感

Y：新システムでは、セキュリティにも気をつけておられるようですね。

M：新システムでは、NISを使わないようにしました。NISを利用している限り利用者のパスワードが漏えいする危険性を避けられませんから。このように考えて、NISを利用しない新システムに切り替えている移行の時期に、NISのデータベースが漏えいした危険性があることが分かるという、非常にタイミングの悪い話がありました。NISのデータベースが漏えいすると、そこから一般学生の技術レベルでも利用者のパスワードが暴かれてしまう危険性があります。

Y：あらー。京大ではそういうことにも気をつけないといけないんですね。

M：こういうことができる技術レベルを持つ学生は、いまや京大に限らずどこにでもいると思うんですよ。ネットワークを通じていろいろな情報やツールがはんらんしていますから。
　ただこれまでは、技術レベルを高める過程において同時に倫理的なレベルも高まっていたと思うんですよ。たとえば、NISを利用した環境では「データベースを入手してパスワードを暴くことができる」という技術的な問題を知るころには、それを実際の行動に移してはいけないという倫理的な教育も行われていたと思うんです。そして、この「利用者の技量とモラルのバランスを信頼する」というモデルの上に、これまでのUNIX文化や教育用計算機システムは構築されてきたわけです。
　今回の件に対応する中で、「管理者が組織内部の人間を信用するというモデルが、教育現場においても崩れてしまった」ことを痛感させられました。これからの教育現場のセキュリティを守るという観点においては、「利用者を信用するセキュリティモデルを利用しない」ということと、「利用者に対して情報の取り扱いについてのモラルを教育する」ことがますます重要になってくると思います。よくも悪くもそういう時代になってしまったということなんでしょうね。

Y：寂しい気がしますが、管理者はそんなことをいっている場合ではなくて、丸山さんのように勇敢に立ち向かっていかないといけないということなんですね。貴重なお話をどうもありがとうございました。

注1　学術情報メディアセンター
詳細については、次のURLで参照できる。
http://www.media.kyoto-u.ac.jp/

注2　旧システム
丸山さんによると、「旧システムの設計時（1997年）には、WindowsよりもUNIXのほうが利用者が多いだろうと推測されており、UNIX端末が800台、Windows端末が400台に決まりつつあったが、仕様策定時の土壇場で、UNIX端末400台、Windows端末800台に変更された」という。

注3　利用者用端末
利用者用端末の仕様は次のとおり（これ以外にも、Mac OS XがインストールされたPower Mac G4（M7681J/A）もある）。
機種：日立 FLORA 330 DK3（CPU：Pentium4/1GHz）
ホストOS：Windows 2000
ゲストOS：Vine Linux 2.1.5
メモリは256MB搭載し、WindowsとVirtual Machineに128MBずつ

注4　大トラブルを経験
1999年4月1日に、NISのサーバー自体が動かなくなり、ユーザーがシステムを利用できなくなる状態が1週間ほど続いた。原因は、ユーザー数が3万人を超えたところで、そのとき使っていたNISのデータベースの制限値を超えたため。

注5　セキュリティ的に甘い部分がある
NIS環境では、パスワードファイルの一覧をユーザーが簡単に取得できることが知られている。また、このファイルの中でパスワードは暗号化されているが、クラックツールを利用して解読できることもある。

注6　この環境のメリットと制限内容を説明
センターのWebページで、ログイン時におけるホームディレクトリの利用選択について説明されている。
http://www.ipse.media.kyoto-u.ac.jp/services/homedir.html

注7　Active!Mail
メールサーバーからIMAPで受信し、HTTPに変換後Web画面に表示するWebメールソフトウェア。トランスウエアの製品。
http://www.transware.co.jp/

私のUNIX #5 ～丸山伸さんのUNIX～

●OS環境：FreeBSD 4.7-STABLE

　最初にUNIXに触れたのは学部生のころだったのですが、はじめて自分の所有する端末にUNIXを導入したのは、ちょうど10年前、大学院に入ったばかりのときでした。FDの山と格闘しながらインストール作業を頑張ったのを懐かしく覚えています。それ以来ずっと変わらずFreeBSD派です。

●シェル：tcsh

　tcshです。

●シェルの設定：ほぼデフォルト

シェルの設定で特徴的なところといえば、このあたりでしょうか？　.tcshrcから抜粋してみました。

set promptchars="%#"
set prompt="%m{%n}[%~]%h %#"
set autolist=beepnone
bindkey ^N history-search-forward
bindkey ^P history-search-backward
set correct=cmd